Base de datos

Introducción
1.1. Introducción a las bases de datos.
1.1. Historia del procesamiento de base de datos.
1.2. Base de datos.
1.3. Características de un Sistema de base de datos.
1.4. Ventajas de una base de datos.
1.5. Desventajas de una base de datos.
1.6. Objetivos de una base de datos.
1.7. Componentes de una base de datos.
1.8. Manejador de una base de datos.
1.9. Funciones de un manejador de base de datos.
1.10. Arquitectura de un sistema de base de datos.
1.11. Diccionario de datos.
1.12. Administrador de base de datos.
1.13. Modelos de datos.
1.13.1.Modelo conceptual de datos.
1.13.2.Modelo entidad-relación.
1.14. Ejemplos de modelo de base de datos.

Ramírez Ramírez
1
 Base de datos

1.1.Historia del procesamiento de bases de datos.

A mediados de los 60s, las grandes corporaciones estaban produciendo

datos a altas velocidades en los sistemas de procesamiento de archivos, pero
los datos se volvían difíciles de manejar y los nuevos sistemas estaban siendo
cada vez más dificiles de desarrollar. Además la administración requería ser
capaz de relacionar los datos de un sistema de archivo con los de algún otro
sistema, no sólo manejar los datos de forma aislada, sino trabajar con las
posibles relaciones entre los mismos.

Las limitaciones en el procesamiento de archivos evitaron la fácil

integración de los datos. Sin embargo, la tecnología de base de datos ofrecía la
promesa de una solución a tales problemas y algunas compañías empezaron a
desarrollar bases de datos organizacionales. Las compañías centralizaron sus
datos operativos. Las aplicaciones fueron inicialmente sistemas de transacción y
procesamiento a nivel de toda la organización.

En la epoca de los años 70’s, el procesamiento de base de datos se

utilizó en corporaciones importantes y en organizaciones grandes como
fundamento de enormes sistemas de transacción y procesamiento utilizando
equipo de cómputo de grandes dimensiones, posteriormente cuando se
vuelven populares las microcomputadoras, la tecnología de bases de datos
emigro a las microcomputadoras y fue aprovechada por usuarios individuales en
aplicaciones personales.

Otra desventaja fue la vulnerabilidad, si un sistema de procesamiento

fallaba, todas las aplicaciones dependientes quedaban inutilizadas; Sin embargo
la situación mejoró de manera gradual, los profesionistas del área de hardware
y software construyeron sistemas suficientemente poderosos para dar soporte a
varios usuarios a la vez y tan rápidos como para mantener la carga de trabajo
diaria de las transacciones, se planearon nuevas formas de controlar, respaldar
los datos, evolucionaron los procedimientos normales y a mediados de los 70’s,
las bases de datos podían procesar muy bien las aplicaciónes de una
organización.

Es en este periodo cuando el concepto de bases de datos logra mayor

popularidad y reconocimento en el ambiente de desarrollo de sistemas de
información.
La actual tecnologia de las bases de datos, es el resultado de la evolución
de las mismas a lo largo de varias décadas.

A continuación se definirá que es una base de datos, término al que

podemos encontrar con diversas conceptualizaciones, e interpretaciones, que
ha sido utilizado tanto para referirse a un conjunto de tarjetas índices, un
directorio telefónico, como para identificar a la enorme cantidad de datos que
pueden ser almacenados en sistemas de información empresarial, bancaria,
gubernamental, etc.

Ramírez Ramírez
2
 Base de datos

1.2. Concepto de base de datos.

Bases de Datos:

 Conjunto de datos organizados con características afines entre sí, que

identifican a una entidad en especial, ya sea un objeto o un sujeto,
cualquier colección de información interrelacionada, es una base de datos.

 Una colección de datos interrelacionados, compartidos y controlados.

 Conjunto autodescriptivo de registros integrados, autodescriptivo ya que

puede contener información del usuario, descripción de sí misma, que
nos permite representar las relaciones entre los datos. En donde la
información que se tiene almacenada está disponible para todos los
usuarios del sistema, en el que los datos redundantes pueden eliminarse
o al menos minimizarse.

Ejemplos de base de datos.

 Directorio telefónico, contiene información relacionada y clasificada.

 Archivo clínico de pacientes.
 Historial académico de un estudiante.

La tecnología de las bases de datos se desarrollo para superar las

limitaciones de los sistemas de procesamiento de archivos. Cabe recordar
que los programas de procesamiento de archivos acceden a los archivos de
datos almacenados.
En contraste, los programas de procesamiento de base de datos se
apoyan del manejador de base de datos para acceder a los datos
almacenados.
Esta diferencia es significativa: hace más fácil la tarea de programar las
aplicaciones, los programadores no deben preocuparse por las formas en
las que los datos se almacenan.

1.3. Características de una Base de Datos.

Las características principales de un sistema de base de datos son:

 Una base de datos permite la posibilidad de trabajar con diferentes tipos de

registros dentro de un conjunto de datos.
 En una base de datos, la información es fácil de encontrar.
 Eliminación de redundancia de la información.
 Consistencia de la información.
 Integridad de la información.
 Información compartida.

1.4. Ventajas del Sistema de base de datos.

Ramírez Ramírez
3
 Base de datos

Un sistema de base de datos ofrece ventajas en comparación a un sistema

de archivos convencionales, a continuación se describen las más importantes.

 Reducir la redundancia.
 Evitar la inconsistencia.
 Compartición de datos.
 Integración de los datos: Combinar los datos para un uso común.
 Integridad de los datos: Precisión y consistencia de los valores de los datos
en la base de datos.
 Independencia de datos.
 Mejor administración de la base de datos.

1.5. Desventajas de las Bases de Datos.

Al igual que una base de datos bien diseñada ofrece ventajas significativas,
es necesario comentar algunas desventajas que pueden estar presentes en un
sistema de base de datos.

Costosas: En ocasiones requiere de Hardware (máyor capacidad de

memoría, una computadora más poderosa, equipo de conectividad, etc.).Altos
costos operativos.
Complejidad: Se requiere de personal de programación y de sistemas
altamente calificados, la complejidad en relaciones requiere de personal capaz de
diseñar procesos adecuados de transacciones.
Backup y Recuperación díficil: Debido a la complejidad de operaciones
y a que varios usuarios procesan transacciones concurrentemente, la
recuperación y el respaldo se dificultan, es necesario tener procesos de bloqueo
para garantizar la recuperación y el respaldo adecuado.
Mayor Vulnerabilidad a falla: Una falla en un componente integrado
puede parar el sistema completo.

1.6. Objetivos primarios de la organización de una base de datos

Una base de datos tiene objetivos específicos, sin importar el tipo de

aplicación o transacciones para las cuales sea diseñada.

1. Los datos se utilizan de múltiples maneras, diferentes usuarios, que perciben

de forma diferente los mismos datos, pueden emplearlos.
2. Se protegerá a la inversión intelectual. No será necesario rehacer los
programas y las estructuras lógicas existentes cuando se modifique la base de
datos.
3. Bajo costo. Tanto del almacenamiento, el uso de los datos y los cambios, esto
debido a la integración de la información.
4. Menor proliferación de datos. Las necesidades de nuevas aplicaciones se
satisfacen con los datos existentes, más bien que creando nuevos archivos,
evitándose así la excesiva proliferación de datos.

Ramírez Ramírez
4
 Base de datos

5. Claridad. Los usuarios tienen a su disposición la información requerida

6. Facilidad de uso. Los usuarios tienen fácil acceso a los datos. Las
complejidades internas son ajenas al usuario, gracias al sistema manejador de
la base de datos.
7. Flexibilidad. Los datos pueden ser utilizados o explorados de manera flexible,
con diferentes caminos de acceso.
8. Rápida atención a interrogantes no previstos. Los pedidos espontáneos de
información se atienden sin necesidad de escribir un programa de aplicación,
sino utilizando un lenguaje de alto nível (Consultas Query).
9. Facilidad para el cambio. La Base de datos puede crecer y variar sin interferir
con las maneras establecidas de uso de los datos.
10. Precisión y coherencia. Se utilizan controles de precisión, evitando versiones
múltiples de datos.
11. Reserva. Se evita el acceso no autorizado a los datos. Los mismos datos
pueden estar sujetos a diferentes restricciones de acceso para diferentes
usuarios.
12. Protección contra pérdida o daño. Los datos están protegidos contra fallas y
catástrofes.
13. Disponibilidad. Los datos se encuentran disponibles para los usuarios cuando
así lo requieran.

1.7. Componentes Básicos en un ambiente de sistema de base de

datos

Considerando que un sistema de base de datos es una organización de

componentes que definen y regulan la recolección, almacenamiento,
administración y uso de los datos en un mismo ambiente, en este sistema existen
componentes importantes y necesarios, a continuación se describen:

1. El esquema. Describe las relaciones lógicas y físicas existentes entre los

registros de la base de datos, las reglas que rigen el diseño y el uso del
sistema.

2. El Hardware.Son todos los dispositivos físicos del sistema, el más básico

es la computadora, aunque en hardware también se incluyen los
periféricos, esto es los componentes que controlan las entradas y las
salidas de los datos (impresoras, teclados, lectores ópticos, dispositivos de
conectividad, etc.).
3. El Software. Los programas utilizados en la administración de datos, y
pueden ser:
• Software de base: Sistema operativo, hace que los programas
funcionen y sean administrados correctamente en los dispositivos de
almacenamiento, (DOS, OS/2, Windows, UNIX, etc.).
• Programa Manejador de base de datos (DBMS):Administra y
organiza los datos (Access, SQL Server de Microsoft, Oracle, DB2,
etc.).

Ramírez Ramírez
5
 Base de datos

• Programas de aplicación y utilierías: Se crean y utilizan para acceder

y manipular los datos, esto es la creación de reportes, tabulación y/o
graficación de resultados, etc.).

4. Datos. Estos son el conjunto de hechos almacenados en la base de datos,

son la materia prima que una vez procesada genera información.

5. Las personas. Los usuarios de la base de datos, considerando

administradores, diseñadores de la base de datos, analistas, capturistas,
gerentes de empresa, etc., es posible clasificar a las personas en :
• Administradores de base de datos. Conocidos como DBA
(Planeación y diseño de la base de datos, Administración de los
recursos que intervienen en la misma, es el responsable del
esquema de la base de datos).
• Diseñadores de base de datos.
• Analistas de sistemas.
• Programadores de aplicaciones.
• Usuarios finales. Quienes requieren información para desarrollar
sus responsabilidades, normalmente interactúan con el sistema
manejador de base de datos de dos maneras:
 Indirectamente: Através de programas de aplicación.
 Directamente, usando un lenguaje de consulta, el más
común es el SQL o (Structured Query Language).

Uno de los elementos más importantes es el manejador de base de

datos, ya que realiza funciones de suma importancia para garantizar la
integridad y consistencia en la información. Enseguida se describe a un
manejador de base de datos, así como las funciones principales que este tiene.
Sistema Manejador de base de datos.

1.8. Manejador de base de datos. DBMS (Data base management system)

Colección de programas que permiten accesar y manipular a los datos,

un DBMS apoya en actividades relevantes para el buen funcionamiento de un
sistema, tales como: administrar a un diccionario de datos, administrar el
almacenamiento de los datos, administrar la seguridad de los mismos, controlar
el acceso a los usuarios, administrar respaldos y recuperación, administrar la
integridad de los datos y accesar a bases de datos e interfaces de programación
de aplicaciones.

1.9. Las Funciones principales de un DBMS son:

a. Crear y organizar la base de datos.

b. Establecer y mantener las trayectorias de acceso a la base de datos, de tal
manera que los datos en cualquier parte de la base se puedan accesar
rápidamente.
c. Manejar los datos de acuerdo con las peticiones de los usuarios.
d. Mantener la integridad y seguridad de los datos.

Ramírez Ramírez
6
 Base de datos

e. Administración de tareas de respaldo y recuperación.

f. Registrar el uso de las bases de datos.
g. Administración del diccionario de datos.
h. Administración del almacenamiento de datos.

El DBMS interpreta y procesa las peticiones del usuario para recobrar

información de la base, sirve de interfase entre las peticiones del usuario y las
bases de datos.

Cualquier DBMS cuenta con los siguientes elementos :

 Lenguaje de consulta (SQL. Structured Query Language). Aquel lenguaje que

no tiene procedimientos, esto es el usuario pide la información que requiere sin
específicar cómo debe hacerse, permite a los usuarios manipular y consultar
datos para extraer la información útil.

Ejemplo. Desplegar los datos de los alumnos.

Select * from Alumnos.

Con esta sentencia es suficiente para conocer toda la información que se

tenga almacenada en la tabla alumnos, no se requiere especificar detalles de
apertura de archivo, de lectura, etc., el SQL realiza las operaciones y presenta
resultados.

 Lenguaje de definición de datos (DDL. Data definition Language). Lenguaje

descriptor de datos, define las estructuras y los datos.

Ejemplo. Crear una tabla de Alumnos.

Create table Alumnos

(
No_mat Int not null,
Nombre char(30) not null,
Email char(20),
Primary key (No_ctrl)
)

 Lenguaje de manipulación de datos. (DML. Data Manipulation Language).

Lenguaje que permite la modificación y manipulación de los datos.

Ejemplo. Insertar un registro a la tabla de Alumnos.

Insert into Alumnos values (0256789,’Luis Pérez’,’[email protected]’)

Ramírez Ramírez
7
 Base de datos

Hablar de un sistema de base de datos implica considerar una arquitectura

que conforma a la misma con características especificas y niveles definidos,
enseguida se mencionan los niveles que integran esta arquitectura..

1.10. Arquitectura de un Sistema de Base de Datos

La arquitectura de un Sistema de base de datos está dividida en tres

níveles generales. Nível interno, nivel externo y conceptual.

Nível Interno: Es la forma en que los datos son almacenados en un dispositivo

de almacenamiento, es el más cercano al almacenamiento físico.

Nível externo: Es la forma en la cual los datos son vistos por usuarios
individuales. (vista parcial de la B.D.), es el más cercano a los usuarios, por
ejemplo la información que se puede observar en un cajero de banco, contando
con una cuenta de banco y un usuario.

Nível conceptual : Es el nível de mediación entre los dos niveles anteriores, es la

forma en la cual los datos son vistos por los diseñadores, analistas y
administradores de una base de datos (vista total de la B.D.).

1.11. Diccionario de Datos.

Un Diccionario de datos es un lugar central de información que contiene

descripciones de los datos, tales como tipo, significado, relaciones con otros datos,
datos de los datos, tambien conocido como metadatos.

Existen herramientas de apoyo en la creación de un Diccionario de datos,

el cual se puede integrar dentro de un sistema de manejo de base de datos o
tratarse aisladamente.

El diccionario de datos del DBMS proporciona una característIca al DBMS

de autodescriptivo.

Un diccionario de datos preferentemente debe estar automatizado, puesto

que si es manual será difícil satisfacer las necesidades del diseñador en cuanto a
la definición de los datos.

Objetivos básicos de un diccionario de datos

 Guardar la descripción de todos los objetos que interactúan con la base

de datos.
 Permitir el manejo y la documentación de los datos: definiendo o
registrando cada campo, el tipo de dato, formato de despliegue en
pantalla, reglas de validación, de tal manera que cada persona que vaya a
usar los datos conozca exactamente lo que significa.
 Datos de los creadores de la base de datos, usuarios y administradores de
las bases de datos.

Ramírez Ramírez
8
 Base de datos

 Definir las relaciones entre elementos de datos, incluidos los elementos

que sean obligatorios u opcionales, la cardinalidad, etc.

1.12. Administrador de base de datos DBA.

El DBA es la persona (o grupo de personas) responsables del control

general del sistema de Base de Datos.

Responsabilidades del DBA.

 Decidir el contenido de la información de la BD.

 Auxiliado por los usuarios escribir los subesquemas, y asegurar que los
datos requeridos por los usuarios estén siempre disponibles.
 Definir procedimientos de revisión, de autorización y de validación.
 Definir una estrategia para respaldo y recuperación.
 Controlar el funcionamiento y responder a requerimientos cambiantes.
 Determinación de standares.

1.13. Modelo de Base de Datos.

Para realizar un sistema de base de datos funcional y eficiente es necesario

haber realizado un diseño correcto, para esto es necesario iniciar el modelado de
la base de datos que represente la realidad y los detalles reelevantes del sistema
a diseñarse. A continuacion se definen algunos conceptos que se utilizan en el
diseño de una base de datos.

Modelo.
Una representación de la realidad que retiene sólo detalles seleccionados.
El modelo expresa las entidades y sus relaciones y es la herramienta usada para
representar la organización conceptual de los datos.
Los modelos conocidos actualmente son:
Modelo de datos.
Representación gráfica relativamente simple de estructuras de datos del
mundo real.

ANSI(American National Standards Institute/Standards Planning and

requirementes Comité (ANSI/SPARC), define tres tipos de modelos de acuerdo
con su grado de abstracción conceptual, externo e interno.

Modelo Interno.
El modelo interno es utilizado por los desarrolladores que trabajan con
manejadores de tipo jerárquico y de redes, ya que estos modelos especifican
detalles de almacenamiento de los datos y rutas de acceso.

Modelo externo.

Ramírez Ramírez
9
 Base de datos

Este modelo muestra la visión de del ambiente de datos de los usuarios

finales.
Cada modelo externo incluye entidades, relaciones, procesos y
restricciones apropiadas definidas por las reglas de negocio.

Modelo físico.
Este modelo es el que funciona en el nivel más bajo de abstracción y
describe como son almacenados los datos en los medios magnéticos de
almacenamiento. Este modelo depende tanto del hardware como del software.
Este modelo es utilizado por desarrolladores que diseñan bases de datos
jerárquicas y de red, las cuales requieren mayores detalles e almacenamiento
de datos.

Modelo
Modelo Externo
Conceptual

Modelo
Interno

Modelo Externo

Modelo Físico

Fig. 1 Modelos de base de datos.

Los modelos de datos:

 Modelo conceptual.
 Modelo entidad-relación.
 Modelo orientado a objetos.
 Modelo semántico.

1.13.1. Modelo conceptual. Representa una visión global de los datos, en

una representación de datos a nivel empresarial. Este modelo es la base para la
identificación y descripción de los objetos de datos principales, el modelo
conceptual más utilizado es el modelo entidad-relación (E-R).

Ramírez Ramírez
10
 Base de datos

1.13.2. Modelo entidad-relación. Este modelo esta basado en una

percepción del mundo real que consta de una colección de objetos básicos,
llamados entidades, y de relaciones entre objetos. Una entidad es una cosa u
objeto en el mundo real. Por ejemplo, cada persona es una entidad, y las cuentas
bancarias pueden ser consideradas entidades.
El modelo proporciona un lenguaje para expresar el modelo de datos de
los usuarios o la estructura de los datos y sus relaciones en el ambiente de
trabajo de los usuarios.
Este modelo fue introducido por Peter Chen en 1976 estableciendo las
bases para el mismo.
El modelo E-R además de entidades y relaciones representa ciertas
relaciones que los contenidos de la base de datos deben cumplir. Una relación
es la correspondencia de cardinalidades, que expresa el número de entidades
con las que otra entidad se puede asociar.
Las estructuras lógicas de una base de datos se pueden expresar
graficamente mediante un diagrama E-R, que consta de los siguientes
componentes:

Símbolos modelado entidad relación

Símbolo Representación

ALUMNO Entidad Alumno.

Rectángulo. Representan entidades.

Entidad de Relación.
Rombos: Representan relaciones entre conjuntos
de entidades.

Atributo
Elipses: Representan atributos.

_______ Relación
Líneas: Unión de entidades.
1: Lado uno de la relación.
* ó M: Lado muchos de la relación.
1, *, M

Tabla 1. Simbología modelo E-R.

Conceptos utilizados en el diseño de una base de datos.

Atributo. Permiten describir a una entidad. Por ejemplo: el nombre, rfc, etc de un
empleado.

Ramírez Ramírez
11
 Base de datos

Valor nulo. Un valor de un atributo que no existe en una instancia

específica.
Clave. Un valor que siempre puede utilizarse para identificar unicamente una
instancia.
Clave primaria. clave candidata que el diseñador elige de la base de datos
como el medio principal de identificar entidades dentro de un conjunto de
entidades.
Clave externa. Clave primaria de una tabla externa.
Clave compuesta: Una clave compuesta de más de un atributo.

NÚMEROCUENT
CALLECTE A
SALDO
RFC
TIEN
CLIENTE CUENTA
E

NOMBR
E
CIUDADCLIENTE

Fig. 2. Ejemplo de diagrama de E-R Modelo Chen.

1.1.4. Descripción de ejemplo:

 Un cliente tiene varias cuentas de banco.

 Este modelo representa a las entidades Cliente y cuenta, además de una
tabla generada por la relación denominada Tiene.
 La tabla Cliente contiene los atributos :RFC, Callecte, nombre,
ciudadcliente.
 La tabla Cuenta contiene los atributos :Númerocuenta, saldo.

Una variación del modelo Chen es el modelo de Pata de gallo.

Ramírez Ramírez
12
 Base de datos

Modelo de Pata de gallo. Desarrollado por C.W. Bachman, la diferencia entre

el modelo Chen y este modelo es la representación de conectividad, cuando
para Chen es 1 y M, para el modelo de pata de gallo es (0,1), (0,N), (1,1), (1,
N).

A continuación se muestra un ejemplo del modelo de pata de gallo.

Fig. No.3 Ejemplo Diagrama Pata de gallo

Descripción de ejemplo:

 Un empleado sólo tiene un puesto.

 Un Puesto puede tener a varios empleados
 Este modelo representa a las entidades Puesto y Empleado,
 La tabla Empleado contiene los atributos: Cve_emp, nombre, Dir, RFC.
 La tabla Puesto contiene los atributos :Cve_pto, puesto, sueldo.

CLIENTE Tiene FACTURA

1 M

Contiene

PRODUCTOS

Fig. No.4. Ejemplo Modelo conceptual de un sistema de Facturación.

Ramírez Ramírez
13
 Base de datos

Descripción del modelo.

• Una factura contiene muchos productos.

• Un producto se factura en N facturas.
• Un cliente puede recibir muchas facturas
• Una factura la recibe sólo un cliente

Modelo orientado a objetos. Un modelo que representa las entidades del

mundo real como objetos en lugar de como registros. Un objeto contiene valores
almacenados en variables de ejemplares dentro de ese objeto. Un objeto tambien
contiene fragmentos de codigo que operan en el objeto. Estos fragmentos de
código se llaman métodos.
Los objetos que contienen los mismos tipos de valores y los mismos métodos se
agrupan juntos en clases. Una clase puede ser una definición de tipo para los
objetos.

Modelo de datos semántico. Un modelo que captura los significados de

las entidades del mundo real y sus interrelaciones. Este modelo fue originalmente
desarrollado con el propósito de incrementar la efectividad y precisión del diseño
de bases de datos. El modelo E-R de Chen ha sido el modelo semantico más
popular, es identificado también como modelo conceptual.

Especialización. Un conjunto de objetos que es un subconjunto de otro

conjunto de objetos.

Generalización. Un conjunto de objetos que es un superconjunto de (o que

contiene a) otro conjunto de objetos.

Interrelación. Un enlace entre instancias de dos conjuntos de objetos.

Cardinalidad. El número máximo de instancias de un conjunto de objetos

que puede estar relacionado con una sola instancia de otro conjunto de objetos.

Ejemplo:
1. Para una interrelación entre un supervisor y un departamento, la cardinalidad es
de una a una, en donde el uno es representado por “1”.

Supervisor 1,1 1,*

SUPERVI 1,1 Departamento
SA

Fig. 5. Interrelación de uno a uno.

Un supervisor, supervisa a un departamento, y un departamento es supervisado

por una persona, este el caso de una relación de uno a uno 1 a 1.

Ramírez Ramírez
14
 Base de datos

2. Para una interrelación entre un supervisor y empleados , la cardinalidad es de

una a muchos, en donde el muchos podra ser representado por un “*”, o la letra
“m”.

Supervisor 1,1 1,*

SUPERVI 1,* Empleado
SA

Fig. 6. Interrelación de uno a Muchos.

Un supervisor supervisa a muchos empleados. Un empleado tiene sólo un

supervisor, este es el caso de una interrelación de uno a muchos,

3. En una interrelación entre alumnos y materias cursadas, la cardinalidad es de

muchos a muchos.

Alumno 1, * 1,*
CURSA
*,1 Materias

Fig. 7. Interrelación de muchos a muchos.

Un alumno cursa muchas materias, una materia la cursan muchos alumnos. Este
es el caso de una interrelación muchos a muchos.

Interrelación funcional. Una interrelación que tiene una cardinalidad maxima de

valor 1 en al menos una dirección.

Cardinalidad uno a uno. Una cardinalidad de la interrelación que es 1 en ambas

direcciones.

Cardinalidad uno a muchos. Una cardinalidad de la interrelación que es una en

una dirección y muchos en la otra.

Cardinalidad muchos a muchos. Una cardinalidad de la interrelación que es

mucho en ambas direcciones.

Reglas que determinan las interrelaciones (Cardinalidad).

Las siguientes reglas determinan las acciones que deben seguirse, una vez
analizadas las interrelaciones que existen entre diferentes entidades.

Ramírez Ramírez
15
 Base de datos

Regla 1. Si dos tablas tienen una interrelación de uno a uno (1 a 1), entonces el
campo clave de una de las tablas debe aparecer en la otra tabla.

Ejemplo.

Empleado 1 1 Puesto

Fig. 8. Cardinalidad de Uno a uno.

• Un empleado pertenece a un puesto.
• Un puesto sólo es de un empleado

Considere que este caso es de una egresa pequeña, en donde sólo hay un puesto
por cada empleado.

Regla 2. Si dos tablas tienen una interrelación de uno a muchos (1 a *), entonces
el campo clave de la tabla del (1) debe aparecer en la tabla del muchos (*).

Ejemplo.

Factura M 1 Cliente

Fig. 9. Cardinalidad de Uno a muchos.

• Una factura se emite para un cliente

• Un cliente puede tener muchas facturas.

Regla 3. Si dos tablas tienen una interrelación de muchos a muchos (* a *),

entonces debe crearse una nueva tabla que tenga como mínimo los campos
claves de las dos tablas.

Ejemplo.

Factura M M Articulos

Fig. 10. Cardinalidad de muchos a muchos.

• En una factura se facturan varios articulos.

• Un articulo se factura en varias facturas.

Ramírez Ramírez
16
 Base de datos

Cardinalidades basicas de las interrelaciones.

Cardinalidad Notacion Ejemplos

Uno-uno 1:1 o 1-1 Un supervisor supervisa un
departamento.
Un departamento es atendido por
un supervisor.
Uno-muchos 1:* o 1-* Un empleado esta en un departamento.
Un departamento tiene muchos
empleados
Muchos-muchos *:* o*-* Una factura tiene muchos
productos
Un producto esta en muchas
facturas
Tabla 2. Cardinalidades

Ejemplo de modelo de base de datos.

1. Realice el diseño conceptual de una base de datos que permita la creación

de una orden de compra semejante a la siguiente:

SOFTSIST
ORDEN DE COMPRA

Fecha Número de orden Número de vendedor

12/10/2007 2132413 856

No_Art Descripción Precio Cantidad

3821 Caja lapices #2 45.00 2
4919 Caja de papel 65.00 1

Subtotal 155.00
IVA 15.50
Total 170.50

Fig. 11. Formato Orden de Compra.

Ramírez Ramírez
17
 Base de datos

Resolución. Modelo Conceptual para la creación de una base de dat6s que

permite generar una Orden de Compra.

NÚMERO_VEN
VENDEDOR NOMBRE
DESCRIPCIO
N

1
PRODUCTO NÚMERO
*
* INCLUYE *
ORDEN FECHA

PRECIO
NO_AR IMPUESTO
T cantidad
CANTIDAD

TOTAL

Fig. 12 Diseño conceptual.

La interrelación *:* nos muestra que es necesaria la creacion de una tercer

tabla, denominada INCLUYE, la cual contiene datos de la interrelación como son el
no_Art, número, además de la cantidad de articulos ordenados.

Ejemplo: CANTIDAD

NOINVENTARI INCLUYE
NÚMERO
O

Fig. 13. Creación de nueva tabla.

2. Modelo de base de datos relacional.

2.1. Modelo relacional de base de datos.
2.2. Conceptos fundamentales de modelo relacional.

Ramírez Ramírez
18
 Base de datos

2.3. Transformación de un modelo conceptual a un modelo relacional.

2.4. Restricciones de integridad.
2.5. Proceso de Normalización.
2.5.1. Primera forma normal.
2.5.2. Segunda forma normal.
2.5.3 Tercera forma normal.

Ramírez Ramírez
19
 Base de datos

UNIDAD II Modelo Relacional de Base de datos.

2.1. Modelo relacional de base de datos.

Una vez que las bases de datos fueron implementadas y utilizadas con
exito surgieron diferentes formas de organizar y representarlas, surgieron
diferentes modelos, modelo Jerárquico, modelo de redes, estos modelos dieron
pauta a la creación del modelo de base de datos relacional, el cual hasta la
fecha es reconocido como uno de los modelos más eficientes y que ofrece
ventajas. A continuación se describen brevemente sus antecedentes.

El concepto base de datos relacional fue utilizado por primera vez por el
Dr. Codd en 1970, el cual publicó un artículo en el que aplicaba los conceptos
de una rama de las matemáticas llamada algebra relacional, a los problemas de
almacenar enormes cantidades de datos. Este artículo dio inicio a un
movimiento en la comunidad de las bases de datos que en muy poco tiempo
condujó a la definición del modelo de bases de datos relacionales.

El modelo relacional surge como un intento de simplificar la estructura de

las bases de datos, eliminando estructuras padre/hijo del modelo jerárquico y en
su lugar representaba todos los datos como tablas conformadas a su vez por
renglones y columnas con valores de datos.

Ejemplo.

Esta tabla almacena información de libros, cada columna representará

datos del libro, como el título, autor, editorial, etc. En cada renglón se almacena
la información referente a un libro.

Entidad Libro

Título Autor Editorial

Demian Hermann Hesse Sayrols
Cobol Javier Ceballos Macrobit

Tabla 3. Ejemplo de Entidad o tabla.

El modelo de base de datos relacional es un modelo simple, poderoso y

formal de representar la realidad. Este modelo facilita la construcción de
consultas del usuario, dando como resultado una alta productividad de los
programadores de la base de datos.

A continuacion se muestran conceptos utilizados en el diseño de base de datos

relacional.

2.2. Conceptos fundamentales del modelo relacional.

Ramírez Ramírez
20
 Base de datos

Tabla, Entidad o Afinidad: Una entidad puede ser llamada también como
afinidad o tabla, es un objeto que existe y es distinguible de otros objetos,
identifica unicamente un objeto o sujeto específico del universo, representada
por un conjunto de atributos, renglones y columnas, ejemplo:
Tabla libro, tabla alumno, tabla empleado, etc.
Esquema: la organización conceptual de toda la base de datos vista por su
administrador, es la colección de tablas, de datos que conforman a las tablas y
relaciones que se generan.
Atributos: descriptores de la entidad de la cual se almacena información, Las
columnas corresponden a los atributos (título, editorial, autor).
Dominio del atributo:El conjunto de todos los valores posibles para un atributo
en particular.
Relación: Tabla que se genera a partir de la relación o asociación de dos o más
tablas o entidades existentes.
Grado de la relación: Es el número de columnas en una tabla.
Cardinalidad de la relación Expresa el número específico de ocurrencias de
una entidad asociadas con una ocurrencia de la entidad relacionada.
Llave o clave.Es el identificador único de cada tupla.
Clave primaria. Clave que el diseñador elige de la base de datos como el
medio principal de identificar un registro o tupla dentro de una tabla.
Clave compuesta: Una clave conformada por más de un atributo.
Clave candidata: Cualquier conjunto de atributos que puede ser elegido como
una clave de una relación.
Clave externa: Clave primaria de una tabla externa; usada para indicar enlaces
logicos entre relaciones.
Tupla : Conjunto de atributos que representan a una unidad.
Valor nulo. El valor dado a un atributo en una tupla, si el atributo es inaplicable
o su valor es desconocido.

En general, una tabla de relación puede tener más de una llave. Cada
llave es denominada llave candidata. Aunque también es posible que un
conjunto de entidades no tenga atributos suficientes para formar una clave
primaria. Un conjunto de entidades de este tipo se denomina conjunto de
entidades débil.
Un conjunto de entidades que tiene una clave primaria se le denomina
entidad fuerte.

Ejemplo de una entidad o tabla es la siguiente:

Tabla Empleado
Noemp Nombre Puesto Profesión
1234 Damian Juarez Contralor C.P.
5234 Javier Carballo Jefe Centro Cómputo L.I.
Tabla 4. Ejemplo de tabla

Entidad: Empleado
Atributos. Noemp, Nombre, Puesto, Profesión.

Ramírez Ramírez
21
 Base de datos

Dominios atributo Noemp: 1234, 5234

Dominios atributo Nombre: Damian Juarez, Javier Ceballosl
Dominios atributo Puesto: Contralor, Jefe Centro Cómputo.
Dominios atributo Profesión: C.P., L.I.

2.3. Transformación de un modelo conceptual en un modelo relacional.

Se ha revisado la representación de un modelo conceptual, ahora se

revisaran los detalles que se deben considerar para realizar la conversión entre
un modelo conceptual y un modelo relacional. Un modelo de datos conceptual
consta de objetos, interrelaciones, atributos, especializaciones, agregados, etc.
Cada uno de ellos podrá ser transformado generando la creación de relaciones
normalizadas.

Transformar conjuntos de objetos y atributos.

FECHA-
NO_SS
NAC
PERSONA

Fig. 14 Descripción Objeto Persona

Este es un objeto con dos atributos. Persona es un objeto y los atributos son
no_ss y fecha_nac

Este diagrama se transforma en una relación con atributos, de la sig. manera.

PERSONA (NO_SS, FECHA-NAC). Se considera que el NO_SS puede servir

como campo clave, ya que identifica unicamente a la persona.
El campo subrayado representa al campo llave.

Transformar modelos sin claves externas.

Suponga el sig. modelo conceptual.

IMPORTE NO_PTO

VENTA

Fig. 15 Transformación modelo

En este caso es posible transformar este diseño al modelo relacional de la sig.
forma.

Ramírez Ramírez
22
 Base de datos

VENTA(Importe, no_pto), solo que no encontramos un campo que pueda servir

de clave, por lo que es necesario añadir un atributo que nos represente a la
clave para esta relación. Ejemplo: VENTA(No_venta, Importe, no_pto)

Transformar la especialización y la generalización de conjuntos de

objetos.

Direccio
No-ss Nombre
n

PERSONA

Conyuge
PERSONA
CASADA

Fig. 16 Transfomación conjunto de objetos.

Este diseño se puede representar en el modelo relacional de la sig.

manera.
Persona casada es una especialización de persona, por lo que hereda todos los
datos de persona, además de sus propios atributos, de tal forma que el modelo
relacional se representaría de la sig. forma.

PERSONA_CASADA (No_ss, nombre, dirección, conyúge)

Clave externa: No_ss referencia a persona
Para eliminar la redundancia, se eliminan los datos repetidos en la tabla de
especialización quedando de la sig. forma:

PERSONA_CASADA (No_ss, conyuge)

Clave externa: No_ss referencia a persona

Transformar interrelaciones.
Las interrelaciones se transforman en tres formas diferentes,
dependiendo de la cardinalidad de las interrelaciones (uno-uno, uno-muchos,
muchos-muchos).

Cliente
Cliente 1,1 Tiene 1,* 1,1 Cuenta
Cuenta
Fig. 17 Transformación interrelaciones

Uno a uno.
Considere:

Ramírez Ramírez
23
 Base de datos

Un cliente sólo tenga una cuenta y una cuenta sólo pertenezca a un cliente.

La transformación de este modelo conceptual al modelo relacional puede

quedar de la sig. manera.

Cuenta(No-cta, No-cte)
Clave externa hace referencia a número de cliente.

Cliente (No-cte,No-cta)
Clave externa hace referencia a número de cuenta.

Uno a muchos.
Considere:
Un cliente tenga muchas cuentas y una cuenta sólo pertenezca a un cliente.

Un cliente puede tener muchas cuentas

Cuenta(No-cta, No-cte, saldo, fecha_apertura)

Cliente (No-cte, nombre, dirección)
Clave externa hace referencia a número de cliente.

Relaciones muchos a muchos.

Considere:
Un cliente puede tener muchas cuentas y una cuenta puede estar asignado a
varios clientes.

Cuenta(No-cta, fecha_apertura)
Cliente (No-cte, nombre, dirección)
Tiene_cuenta(No-cte, No-cta, saldo)
Clave foránea No-cte hace referencia a número de cliente.
Clave foránea No-cta hace referencia a número de cuenta.

2.4. Restricciones de Integridad.

En la realización del diseño de una base de datos es muy importante
considerar a las restricciones necesarias para lograr un buen diseño de la
misma.

Entendiendo por restricción, a las reglas que limitan los valores que pueden
estar en una base de datos.

Las restricciones más importantes son las siguientes:

 Integridad de la entidad. El atributo que es clave de una fila no

puede ser nulo.
Ejemplo

Ramírez Ramírez
24
 Base de datos

No_matricula Nombre Carrera

Juan López Ing. Sistemas

El No_matricula, siendo el campo llave, no puede ser nulo.

Fig. 18 Integridad de la Entidad.

 Integridad referencial. El valor no nulo de una clave externa debe

ser un valor real de la clave de otra relación.

Tabla Factura
Folio Fecha No_cte
1 10/12/2007 100
2 10/12/2007 150

Tabla Clientes
No_cte Nombre Dirección
100 Camila Ortega Otay
120 Jorge Rábago La Mesa
Fig. 19. Integridad Referencial.

La integridad referencial no permitirá generar una factura a un cliente que

aún no está dado de alta en el catálogo.

 Dependencia funcional. El valor de un atributo en una tupla

determina el valor de otro atributo en la tupla.

No_asig. Nombre_asig Créditos

1 Base de Datos 8
2 Lenguajes Algoritmicos 7
3 Desarrollo Humano 5
Fig. 20 Dependencia funcional.

La Dependencia funcional, permitirá conocer cualquier dato de la tupla,

conociendo el valor del campo llave.

El modelo de datos relaciónal de Codd incluye varias restricciones que

se usan para verificar la validación de los datos.

Ramírez Ramírez
25
 Base de datos

• Los valores en las celdas de la tabla, deben ser de valor único; no se

permite repetir grupos, ni tener arreglos como valores.
• Todos los ingresos en cualquier columna (atributo) deben ser del mismo
tipo.
• Cada columna posee un nombre único y no es importante el orden de las
columnas en la tabla.
• En la tabla no pueden ser idénticas dos hileras (tuplas) y no es
importante el orden de los renglones.

La simplicidad del modelo relacional se da desde que todas las

relaciones son definidas independientemente. La relación en el modelo E-R
puede ser representada por la unión entre atributos de diferentes tablas.

Para entender el modelo relacional y la normalización es necesario

conocer los conceptos de dependencia funcional y de clave, de la cual ya
hemos hablado previamente.

Una dependencia funcional es una relación entre uno o más atributos,

esto es un dato será dependiente de otro y podremos encontrar información a
partir de un dato original.

Cuando en una tabla o base de datos no se tiene un diseño correcto de

los datos, se puede incurrir en las siguientes anomalías:

Anomalias de actualización. Inconsistencia de los datos como resultados de

datos redundantes y actualizaciones parciales.

Anomalias de borrado. Pérdida no intencionada, de datos debido a que se

han borrado otros datos.

Anomalias de Inserción. Imposibilidad de adicionar datos en la base de datos

debido a la ausencia de otros datos.
Ejemplo:

Tabla Trabajador.
Id-trab Nombre Oficio Id-sup Id-edificio
1235 Manuel Alvarez Electricista 1511 300
1235 Manuel Alvarez Electricista 1511 400
1412 Martin Pérez Obrero 500
1412 Martin Pérez Plomero 600
1412 Martin Pérez Plomero 450
1412 Martin Pérez Plomero 400
1511 Carlos Díaz Plomero 450
Tabla 5. Entidad trabajador

Esta es una tabla mal diseñada, que muestra redundancia, en datos

como el nombre y el oficio.

Ramírez Ramírez
26
 Base de datos

Esta redundancia no sólo ocupa espacio, sino que puede llevar a perder
la integridad de los datos (pérdida de la consistencia).
Suponiendo que un trabajador atiende a más de un edificio al mismo tiempo y
que además el oficio en una tupla es incorrecto y las demás son correctas. Esto
genera inconsistencia entre las tuplas que contienen información del trabajador.
Este es un ejemplo de anomalías de actualización.

Suponga que un empleado ha dejado de trabajar por un tiempo y el

edificio que tenia asignado fue concluido. Si se desea eliminar las tuplas de los
edificios terminados es posible que la tupla de un trabajador sea borrada y no se
tengan los datos del empleado.Esto se denomina anomalías de borrado.

A modo inverso, puede tenerse contratado un nuevo empleado llamado

Jorge Mejía, si aún no se le asigna un edificio. A esto se le llama anomalías de
actualización.

Para eliminar este tipo de errores es necesario aplicar la técnica de

normalización que nos permita tener un diseño correcto.

2.5. Normalización.
Se han realizado muchos trabajos teóricos acerca de lo que es una
relación bien estructurada. Este trabajo se ha denominado Normalización, Codd,
definió varias formas normales de afinidades.

La técnica de normalización es semejante a lo que comunmente se dice

de que un párrafo en una lectura, debe tener un sólo tema, si un párrafo tiene
más de un tema, debe dividirlo en tantos párrafos como temas se consideren.
La lógica que se aplica a la normalización es cada afinidad normalizada tiene un
sólo tema, Si tiene dos o más, deberá fragmentarse en afinidades o tablas, cada
una de las cuales tendrá un sólo tema.

Estas clases de afinidades y las técnicas para prevenir las anomalías son
llamadas formas normales. Dependiendo de su estructura, una afinidad puede
estar en primera forma normal, segunda forma normal o alguna otra. En su
artículo Ted Codd, estableció la primera, segunda y tercera forma normal. Cada
una de estas formas están anidadas, esto es una afinidad que está en tercera
forma, debe estar en primera y segunda forma normal.

2.5.1.Primera forma normal

Una afinidad está en primera forma normal, si la tupla tiene un campo

definido como campo clave y todos sus valores son atómicos o únicos para
cada atributo en la relación. Esto es que los valores de los atributos no pueden
ser un conjunto de valores o un grupo repetitivo.
Cualquier tabla de datos que cumpla con la definición de una afinidad, se
dice que está en la primera forma normal.

Ramírez Ramírez
27
 Base de datos

Si en una tabla nos encontramos grupos repetitivos es necesario crear

una tabla de relación que interrelacione a las tablas determinadas.

Ejemplo:

Tabla Trabajador.
Id-trab Nombre Oficio Id-sup Id-edificio
1235 Manuel Alvarez Electricista 1511 300,450,500
1412 Martin Pérez Plomero 400.450,500,600
1511 Carlos Díaz Plomero 450,500
Fig. 21 Tabla Trabajador.

En esta tabla se observa que cada empleado puede atender a diferentes

edificios, este es el caso de un atributo como grupo repetitivo, por lo que es necesario
corregir esta tabla creando una nueva tabla de relación.

Trabajador
Id-trab Nombre Oficio Id-sup
1235 Manuel Alvarez Electricista 1511
1412 Martin Pérez Plomero
1511 Carlos Díaz Plomero

Asignación por trabajador

Id-trab Id-edificio
1235 300
1235 450
1235 500
1412 400
1412 450
1412 500
1412 600
1511 450
1511 500
Fig. 22 Tabla Asignación por Trabajador.

2.5.2. Segunda forma normal.

La segunda y tercera forma normal se ocupan de la relación entre los

atributos claves y no claves. Una relación está en segunda forma normal (2FN) si
todos sus atributos que no son claves dependen por completo de la clave, esto
es cada afinidad que tiene un atributo único como clave, está en segunda forma
normal. La clave es sólo un atributo, en forma predeterminada, cada atributo que
no es clave no es funcionalmente dependiente de una parte de la clave; no
puede haber dependencias parciales.Por tanto, la 2FN puede violarse sólo

Ramírez Ramírez
28
 Base de datos

cuando una clave sea compuesta o, en otras palabras, que conste de más de un
atributo.

Ejemplo:
Trabajador

Id-trab Nombre Id-edificio Fecha inicio

1235 Manuel Alvarez 300 01/01/01
1412 Martin Pérez 400 01/04/01
1235 Manuel Alvarez 450 10/03/01
1412 Martin Pérez 500 02/10/01
1412 Martin Pérez 600 03/12/01
Tabla 6. Entidad Trabajador

En esta tabla tenemos los datos del trabajador (id-trab y nombre) cada vez que
aparece una tupla de edificio asignado, existe redundancia en el nombre y
podria accesar datos por id-trabajador y por nombre, esto es una violación a la
2FN.

2.5.3.Tercera forma normal.

Una afinidad está en tercera forma normal si está en segunda forma

normal y no tiene dependencias transitivas. Una dependencia transitiva es un
arreglo de dependencias funcionales. Es posible decir que una relación está en
3FN si para toda dependencia funcional DF: X Y, X es una clave.

Trabajador
Id-trab Oficio Sueldo
1235 Electricista 3.50
1412 Plomero 3.00
1511 Plomero 3.75

Ramírez Ramírez
29
 Base de datos

3. Introducción a SQL.
3.1 Introducción a SQL.
3.1.1 Componentes de SQL
3.1.2 Comandos y clausulas.
3.1.3 Operadores Lógicos
3.1.4 Operadores de Comparación
3.1.5 Funciones Sumarias
3.2. Consultas de Selección.
3.2.1. Consultas Básicas
3.2.2. Ordenar los registros
3.2.3. Consultas con predicado
3.2.4. Alias
3.3. Criterios de Selección
3.3.1 Operadores Lógicos
3.3.2 Intervalos de Valores
3.3.3 El Operador Like
3.3.4 El Operador In
3.3.5 Agrupamiento de Registros y Funciones Sumarias
3.4 Subconsultas
3.5 Ejercicios.

Ramírez Ramírez
30
 Base de datos

3. Introducción al lenguaje SQL.

Lenguaje estructurado de consulta.

3.1 Introducción a SQL.
SQL es una herramienta para organizar, gestionar y recuperar datos
almacenados en una base de datos automatizada. El nombre SQL es una
abreviatura de Structured Query Language (Lenguaje estructurado de
consultas), SQL trabaja con bases de datos relacionales.
SQL es mucho más que una herramienta de consulta, aunque ese fue su
propósito original y recuperar datos sigue siendo una de sus funciones más
importantes. SQL se utiliza para controlar todas las funciones que un DBMS
proporciona a sus usuarios, incluyendo:

• Definición de datos.
• Recuperación de datos.
• Manipulación de datos.
• Control de acceso.
• Compartición de datos
• Integridad de datos.

Sql no es en sí un lenguaje de programación como el Cobol, C, etc. no

contiene comandos como ciclo for, sentencia if, etc. Sin embargo cuenta
alrededor de 30 instrucciones básicas que permiten al usuario obtener
información cuando y como lo requiera.

Sql juega tiene las siguientes funciones:

• Consultas interactivas.
• Lenguaje de programación de base de datos.
• Lenguaje de Administración de base de datos.
• Lenguaje cliente/servidor.
• Lenguaje de base de datos distribuidas.

3.1.1. Componentes de SQL

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y

funciones de agregado. Estos elementos se combinan en las instrucciones para
crear, actualizar y manipular las bases de datos.

Existen dos tipos de comandos SQL

• Los DDL que permiten crear y definir nuevas bases de datos, campos e
índices.
• Los DML que permiten generar consultas para ordenar, filtrar y extraer
datos de la base de datos.

3.1.2. Comandos DDL

Ramírez Ramírez
31
 Base de datos

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
ALTER
definición de los campos.

Comandos DML
Comando Descripción
Utilizado para consultar registros de la base de datos que satisfagan
SELECT
un criterio determinado
Utilizado para cargar lotes de datos en la base de datos en una única
INSERT
operación.
Utilizado para modificar los valores de los campos y registros
UPDATE
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
Utilizada para específicar la tabla de la cual se van a seleccionar los
FROM
registros
Utilizada para especificar las condiciones que deben reunir los
WHERE
registros que se van a seleccionar
GROUP Utilizada para separar los registros seleccionados en grupos
BY específicos
HAVING Utilizada para expresar la condición que debe satisfacer cada grupo
ORDER Utilizada para ordenar los registros seleccionados de acuerdo con un
BY orden específico

3.1.3. Operadores Lógicos

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

3.1.4. Operadores de Comparación

Operador Uso
< Menor que
> Mayor que

Ramírez Ramírez
32
 Base de datos

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

3.1.5. Funciones Sumarias

Las funciones de agregado o sumatorias, se usan dentro de una cláusula

SELECT para devolver un único valor que se aplica a un grupo de registros.

Función Descripción
AVG Calcula el promedio de los valores de un campo determinado
COUNT Devuelve el número de registros de la selección
SUM Devuelve la suma de todos los valores de un campo determinado
MAX Devuelve el valor mayor de un campo especificado
MIN Devuelve el valor menor de un campo especificado

Ejemplos:
Select avg(precio) from productos
Esta sentencia nos regresara un valor que es el promedio de los precios
de todos los articulos de la tabla productos.

Select sum(precio) from productos

Esta sentencia nos regresara un valor que es la suma de los precios de
todos los articulos de la tabla productos.

Select count(no-pto) from productos

Esta sentencia nos regresara un valor que es la cantidad de articulos de
la tabla productos.

Select max(precio) from productos

Esta sentencia nos regresara el precio mayor de los articulos de la tabla
productos.

Select min(precio) from productos

Esta sentencia nos regresara el precio menor de los articulos de la tabla
productos.
3.2. Consultas de Selección
Las consultas de selección se utilizan para indicar al motor de datos que
devuelva información de las bases de datos, esta información es devuelta en
forma de conjunto de registros. Este conjunto de registros es modificable.

3.2.1. Consultas básicas

Ramírez Ramírez
33
 Base de datos

La sintaxis básica de una consulta de selección es la siguiente:

SELECT atributo(s) FROM Tabla;
En donde atributos es la lista de campos que se deseen recuperar y tabla
es el origen de los mismos, por ejemplo:
SELECT Nombre,Teléfono FROM Clientes;
Esta consulta devuelve el campo nombre y teléfono de la tabla clientes.

Cláusula from.
Específica la tabla o las tablas de las que los datos serán obtenidos.

Cláusula where.
Nos permite específicar los renglones que deseamos recuperar, en
función de alguna condición específica.

SELECT Nombre, Teléfono FROM Clientes where nombre=”Camila”;

Esta consulta devuelve el campo nombre y teléfono de la tabla clientes
en donde el nombre del cliente es Camila.

3.2.2. Ordenar registros

Adicionalmente se puede específicar el orden en que se desean
recuperar los registros de las tablas mediante la claúsula ORDER BY Lista de
Campos. En donde Lista de campos representa los campos a ordenar. Ejemplo:
SELECT CódigoPostal, Nombre, Teléfono FROM Clientes ORDER BY Nombre;
Esta consulta devuelve los campos CódigoPostal, Nombre, Teléfono de
la tabla Clientes ordenados por el campo Nombre.
Se pueden ordenar los registros por más de un campo, como por ejemplo:
SELECT CódigoPostal, Nombre, Teléfono FROM Clientes ORDER BY
CódigoPostal, Nombre;
Incluso se puede específicar el orden de los registros: ascendente
mediante la claúsula (ASC -se toma este valor por defecto) ó descendente
(DESC)
SELECT CódigoPostal, Nombre, Teléfono FROM Clientes ORDER BY
CódigoPostal DESC, Nombre ASC;

3.2.3. Consultas con Predicado

Ramírez Ramírez
34
 Base de datos

El predicado se incluye entre la claúsula y el primer nombre del campo a

recuperar, los posibles predicados son:

Predicado Descripción
ALL Devuelve todos los campos de la tabla
TOP Devuelve un determinado número de registros de la tabla
Omite los registros cuyos campos seleccionados coincidan
DISTINCT
totalmente
Omite los registros duplicados basándose en la totalidad del
DISTINCTROW
registro y no sólo en los campos seleccionados.

ALL: Si no se incluye ninguno de los predicados se asume ALL. El Motor

de base de datos selecciona todos los registros que cumplen las condiciones
de la instrucción SQL.
Ejemplo:
Select all from empleados;
Select * from empleados;
TOP: Devuelve un cierto número de registros que entran entre al principio
o al final de un rango especificado por una cláusula ORDER BY. Supongamos
que queremos recuperar los nombres de los 25 primeros estudiantes del curso
2002:
Select top 25 Nombre from Estudiante where curso=2002
order by no_est desc;

DISTINCT :Omite los registros que contienen datos duplicados en los

campos seleccionados.

Por ejemplo, varios empleados listados en la tabla Empleados pueden

tener el mismo apellido. Si dos registros contienen López en el campo Apellido,
la siguiente instrucción SQL devuelve un único registro:
Select distinct apellido from empleados;
Con otras palabras el predicado DISTINCT devuelve aquellos registros
cuyos campos indicados en la cláusula SELECT poseen un contenido diferente.

3.2.4. Alias
En determinadas circunstancias es necesario asignar un nombre a
alguna columna determinada de un resultado obtenido en alguna consulta. Para
esto se utiliza la palabra reservada AS que se encarga de asignar el nombre
que deseamos a la columna calculada.

Ramírez Ramírez
35
 Base de datos

Ejemplo
Sentencia que devuelve la cantidad de empleados en la tabla empleados, la
cantidad obtenida la muestra en un atributo denominado Contador.

SELECT count(nombre) as contador from Empleados;

Sentencia que devuelve el promedio de gastos en la tabla Pedidos, en donde

gastos sea mayor que 100.

SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100

3.3. Criterios de Selección.

En una consulta es posible filtrar los registros con el fin de recuperar

solamente aquellos que cumplan condiciones preestablecidas.

Antes de iniciar hay que recalcar tres detalles de vital importancia.

1. Cada vez que se desee establecer una condición referida a un campo de
texto, la condición de búsqueda debe ir encerrada entre comillas simples;
2. No es posible establecer condiciones de búsqueda en los campos memo
y;
3. Referencía a las fechas. Las fechas se deben escribir siempre en formato
mm-dd-aa en donde mm representa el mes, dd el día y aa el año, hay
que prestar atención a los separadores -no sirve la separación habitual
de la barra (/), hay que utilizar el guión (-) y además la fecha debe ir
encerrada entre (#). Por ejemplo si deseamos referirnos al día 3 de
Septiembre de 2007 se debe hacer de la siguente forma; #09-03-07# ó
#9-3-07#.

3.3.1. Operadores Lógicos

Los operadores lógicos soportados por SQL son: AND, OR, XOR, Eqv,
Imp, Is y Not. A excepción de los dos últimos todos poseen la siguiente sintaxis:

<expresión1> operador <expresión2>

En donde expresión1 y expresión2 son las condiciones a evaluar, el

resultado de la operación varía en función del operador lógico.

Select * from empleados where (edad>25) and (edad<50)

Select * from empleados where (edad > 25) and (edad < 50) or (sueldo = 100)

Select * from empleados where not (estado='soltero')

Ramírez Ramírez
36
 Base de datos

Select * from empleados where ((sueldo > 100) and (sueldo < 500)) or
((ciudad = 'madrid') and (estado = 'casado'))

3.3.2. Intervalos de Valores (Between).

Permite indicar que datos deseamos recuperar según el intervalo de

valores de un campo, la sintaxis del operador Between es:

Select campo(s) from Tabla where campo [Not] Between valor1 And valor2 (la
condición Not es opcional)

En este caso la consulta devolvería los registros que contengan en

"campo" un valor incluido en el intervalo valor1, valor2 (ambos inclusive). Si
anteponemos la condición Not devolverá aquellos valores no incluidos en el
intervalo.

Ejemplo:

SELECT * FROM Pedidos WHERE CodPostal Between 28000 And 28999;

(Devuelve los pedidos realizados en las ciudades con codpostal entre 28000 y
28999)

3.3.3.Operador Like

Se utiliza para comparar una expresión de cadena con un modelo en una

sentencia SQL. Su sintaxis es:

expresión Like modelo

En donde expresión es una cadena modelo o campo contra el que se

compara expresión. Se puede utilizar el operador Like para encontrar valores en
los campos que coincidan con el modelo específicado. Por modelo se puede
especificar un valor completo (Ana María), o se pueden utilizar caracteres
comodín como los reconocidos por el sistema operativo para encontrar un rango
de valores (Like An*).

Ejemplo:
Si introduce Like C* en una consulta SQL, la consulta devuelve todos los
valores de campo que comiencen por la letra C.

Ejemplo:
Sentencia que devuelve los datos que comienzan con la letra P, seguido
de cualquier letra entre A y F y de tres dígitos:

Like 'P[A-F]###'

Ramírez Ramírez
37
 Base de datos

Este ejemplo devuelve los campos cuyo contenido empiece con una letra
de la A a la D seguidas de cualquier cadena.

Like '[A-D]*'

3.3.4. Test de pertenencia In

Este operador devuelve aquellos registros cuyo campo indicado coincide

con alguno de los que pertenecen a una lista.
Su sintaxis es:

expresión [Not] In(valor1, valor2, . . .)

Ejemplo:
Desplegar los datos de los pedidos cuya ciudad este entre la lista de

Select * from pedidos where provincia In (‘Tijuana’, 'Madrid', 'Londres', 'New

York');

Cláusula WHERE

La cláusula WHERE puede usarse para determinar qué registros de las

tablas enumeradas en la cláusula FROM aparecerán en los resultados de la
instrucción SELECT. Si no se emplea esta cláusula, la consulta devolverá todas
las filas de la tabla. WHERE es opcional, pero cuando aparece debe ir a
continuación de FROM.

Ejemplos:
• Desplegar el apellido y salario de los empleados cuyo salario sea >
21000.

Select apellidos, salario from empleados where salario > 21000;

• Desplegar id_producto, existencias de la tabla Productos en donde

existencia sea menor o igual a 1000.

Select id_producto, existencias from productos where existencias <= 1000;

• Desplegar apellido y nombre de la tabla Empleados en donde apellido =

‘Martínez’

Select apellidos, nombre from empleados where apellidos = ‘Martínez’

• Desplegar apellido y nombre de la tabla Empleados en donde apellido

inicie con la letra S y después contenga una cadena de caracteres.

Select apellido y nombre from empleados where apellidos like 'S*';

Ramírez Ramírez
38
 Base de datos

• Desplegar apellido y nombre de la tabla Empleados en donde salario

este entre 200 y 300.

Select apellido, salario from empleados where salario between 200 and 300;

3.3.5. Agrupamiento de Registros

GROUP BY
Agrupa los registros con valores idénticos, para cada registro se crea un
valor sumario si se incluye una función SQL agregada, como por ejemplo Sum o
Count, en la instrucción SELECT.

Sintaxis:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo

GROUP BY es opcional. Los valores de resumen se omiten si no existe

una función SQL agregada en la instrucción SELECT. Los valores Null en los
campos GROUP BY se agrupan y no se omiten. No obstante, los valores Null no
se evalúan en ninguna de las funciones SQL agregadas.

Ejemplo:

Desplegar el id de linea y la suma de stock de la tabla Productos agrupado por

idLinea.

SELECT Id_Linea, Sum(Stock) FROM Productos GROUP BY Id_Linea.

Columnas calculadas.

Es possible realizar columnas calculadas utilizando los operadores

aritméticos descritos anteriormente

Ejemplo:

SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM DetallePedido;

3.4. SubConsultas
Una subconsulta es una instrucción SELECT anidada dentro de una
instrucción SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o
dentro de otra subconsulta.

Una subconsulta puede realizarse mediante comparación o Instrucción sql.

Comparación
Es una expresión y un operador de comparación que compara la
expresión con el resultado de la subconsulta.

Ramírez Ramírez
39
 Base de datos

Instrucción sql
Es una instrucción SELECT, que sigue el mismo formato y reglas que
cualquier otra instrucción SELECT. Debe ir entre paréntesis.

Se puede utilizar una subconsulta en lugar de una expresión en la lista de

campos de una instrucción SELECT o en una cláusula WHERE o HAVING. En
una subconsulta, se utiliza una instrucción SELECT para proporcionar un
conjunto de uno o más valores especificados para evaluar en la expresión de la
cláusula WHERE o HAVING.

El predicado IN se emplea para recuperar únicamente aquellos registros

de la consulta principal para los que algunos registros de la subconsulta
contienen un valor igual.

Ejemplo:
• Despliega todos los productos vendidos con un descuento igual o mayor
al 25 por ciento.:

Select * from productos where idproducto in (select idproducto from

detallepedido where descuento >= 0.25);

Inversamente se puede utilizar NOT IN para recuperar únicamente

aquellos registros de la consulta principal para los que no hay ningún registro de
la subconsulta que contenga un valor igual.

El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza

en comparaciones de verdad/falso para determinar si la subconsulta devuelve
algún registro.

Ejemplo:

Suponga que desea conocer el nombre de las partes suministradas por el

proveedor No. 1

Select parte from Partes where no_pto = (Select no_pto from

Partes_suministradas where S#=s1).

En esta sentencia es necesario realizar una sentencia anidada, debido a que el

no_del proveedor esta en la tabla partes suministradas, pero los datos de la
parte, esta en la tabla Partes, por lo que el resultado de la consulta interna será
el valor de la claúsula Where.

Ramírez Ramírez
40
 Base de datos

3.5. Ejercicios SQL

Tabla Partes Tabla Proveedores

S# Nom Estado Ciudad
No_ Parte Color Estado Precio S1 Salazar 20 Londres
pto S2 Jaramillo 10 París
P1 Tuerca Rojo 12 1.50 S3 Bernal 30 París
P2 Perno Verde 17 2.00
P3 Tornillo Azul 17 4.80
P4 Tornillo Rojo 14 1.20

Tabla Partes_Suministradas
S# No_pto Cant
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 300
S2 P2 300
S2 P2 350
S3 P2 200

Ramírez Ramírez
41
I. Utilizando las tablas anteriores, se resuelven los siguientes ejercicios, usando
las sentencias correspondientes:

1. Encontrar el nombre de la ciudad del proveedor S1.

Select ciudad from Proveedor where S#=”S1”.

2. Encontrar el número y estado de los proveedores cuya ciudad es París.

Select s#, estado from Proveedor where ciudad=”París”.

3. Cual es el nombre del proveedor que surte la parte con mayor cantidad.
Select nombre from Proveedor where s#=(Select s# from Partes_suministradas where
cant= (Select max(cant) from Partes_suministradas.

4. Encontrar el promedio de la cantidad suministrada por cada proveedor.

Select avg(cantidad) from Partes_suministradas group by s#

5. Encuentre el color de la parte 2.

Select color from partes where no_pto= 2

6. Quien es el proveedor cuya ciudad es Londres.

Select s#, nombre from proveedores where ciudad=’Londres’

7. Cuántas partes son de color rojo.

Select count(color) from partes where color= ‘rojo’

8. Encontrar la suma de todos los precios de los artículos, el precio maximo, el

mínimo y el promedio de precios.
Select sum(precio) as suma,max(precio) as maximo, min(precio) as minimo,
avg(precio) as promedio from partes.

9. Encuentra las partes donde el color sea rojo y el precio > 1.

Select * from partes where (color=’rojo’) and (precio>1)

10. Lista a las partes suministradas con una cantidad mayor a 200.
Select * from partes_suministradas where cantidad > 200
Ejercicio SQL

Usando las tablas de la base de datos que se anexan, realiza las sentencias de sql, necesarias para
resolver cada caso.
Art-fact
Productos No-fact No-pto Cantidad
Clave Descripción Precio- Linea
-prod prod 100 1587 160
1587 Motherboard $450.00 01 101 9978 100
Pentium IV 102 2020 150
2020 Impresora Laser HP 175.99 01 102 9147 1000
2145 Impresora Deskjet 150.00 01 103 1587 2500
9052 Monitor Svga 99.99 01 104 2145 1200
9147 Mouse 15.99 01 105 9147 1400
9268 Windows xp 53.21 08 106 2020 1500
Software
9978 Software Creative 55.89 08
107 2020 2000
9987 Aplique SQL (libro) 28.89 05 107 9052 2500
9989 Microsoft (Libro) 25.89 05 108 1587 3000
9997 Microsoft Publisher 97.89 08 109 9997 1000
9998 Cable coaxial 25.20 02 109 9268 5000
110 9978 2000
110 9052 3000
Lineas 111 9989 5000
Cve-linea Descrip-linea 111 9147 2000
01 Equipo 112 9998 9000
02 Cables
05 Librería Facturas
08 Software
Clientes No-fact No-cte Fecha
Nocte Nombre Dir Tel 100 1001 03/12/06
1000 Javier Barragan Otay 23-64-72 101 1003 03/06/07
1001 Enrique Hipodromo 82-25-36 101 1004 25/10/06
Ramírez 102 1002 03/01/06
1002 Camila Ortega La Mesa 85-56-98 102 1003 24/11/06
1003 Martha Ruiz Otay 89-78-48 103 1001 14/06/06
1004 Jorge Gutiérrez Playas 56-85-79 104 1002 25/10/06
105 1003 03/01/06
106 1002 24/11/06
106 1003 14/06/06
107 1001 25/10/06
107 1002 03/01/06
108 1004 24/11/06
109 1003 25/10/06
110 1002 03/01/06
111 1003 24/11/06
112 1004 14/06/06
 Apuntes Docentes Base de datos I

1. Encuentra el total acumulado de precio de productos de la línea Software

2. Despliega los datos de la factura en la cual se le haya facturado al cliente
Camila Ortega.
3. Despliega los precios de los productos de la línea software.
4. Encuentra el nombre de los artículos facturados en la factura 107.
5. Despliega la cantidad de facturas emitidas al cliente Enrique Ramírez.
6. Borra aquellos clientes en donde el estado sea B
7. Encuentra el promedio de precios de los productos de la línea equipo.
8. Despliega la clave y descripción de los productos cuyo precio esta entre 50 y
100.00
9. Despliega el no de factura, el nombre del cliente, de la factura emitida el
03/06/06.
10. Borra a aquellos artículos de la línea cables.
11. Lista en un reporte los datos de los clientes cuyo estado sea A.
12. Despliega el no de producto y los totales facturados por producto.
13. Encuentra los datos de las facturas que se hayan realizado al cliente Martha
Ruiz.
14. Despliega el promedio de cantidades de productos facturados por producto.
15. Despliega el total de cantidad facturado del producto Mouse

Ramírez,Marique
45
 Apuntes Docentes Base de datos I

4. Modelos de base de datos

4.1 Modelo Jerárquico
4.2 Modelo de red.
4.3 Sistemas de B.D. Orientado a objetos
4.4 Sistemas de B.D. distribuidas.

4. Modelos de Sistemas de Bases de Datos

Existen varios enfoques para diseñar un verdadero sistema de base de

datos, y esto es de acuerdo a las estructuras de almacenamiento y formas de
accesar los elementos de los datos.

Existen varios modelos de Base de Datos

• Modelo Jerárquico
• Modelo de Redes.
• Modelo Relacional.
• Modelo de base de datos orientada a objetos.

4.1. Modelo Jerárquico.

Conjunto de registros que se conectan entre sí, guardando la información

por medio de árboles (ligas), existe una relación de padres a hijos y viceversa.
Los sistemas de base de datos jerárquicos requieren que se piense en los datos
colocados en una jerarquía. Cada dato está subordinado a otro excepto el dato
raíz.
En lugar de ser una simple colección de campos, el registro es una colección de
subregistros ó segmentos, cada segmento es parte de un registro.
Un segmento puede contener más de un campo, un nível puede agruparse para
formar un único segmento.
El almacenamiento de los datos en una base de datos jerárquica es tipo plana en
cierta forma controlada y almacenada secuencialmente.

Los manejadores de base de datos jerárquico son:

 IMS(Information Management System).
 TDMS (System Development Corporation’s time-shared Data management
system)
 System 2000.
 Mark IV

Los conceptos de base de datos en el modelo jerárquico son.

Modelo de datos jerárquico.

Ramírez,Marique
46
 Apuntes Docentes Base de datos I

Un modelo de datos en el cual todas las interrelaciones son estructuradas

como árboles.
Padre: La raíz de la estructura arborescente.
Hijo: Un nodo dependiente de otro nodo en un nível superior.
Árbol: Una estructura en red en donde un tipo de segmento hijo es enlazado a un
sólo tipo de segmento padre.
Tipo de interrelación padre-hijo: Interrelación lógica entre un tipo de segmento
padre y un tipo de segmento hijo.

Ventajas del modelo

Las características más sobresalientes del modelo de base de datos

jerárquico ofreció ventajas sobre el modelo de sistemas de archivos. Muchas
características de este modelo fueron el fundamento de los modelos de base de
datos actuales, las ventajas más importantes del modelo jerárquico son:

1. Simplicidad conceptual: Debido a la estructura jerárquica, la relación entre

los níveles es lógicamente simple, lo que facilita el proceso de diseño.
2. Seguridad de la base de datos: La seguridad es ejecutada por el DBMS, de
modo que la seguridad se ejecuta uniformemente por todo el sistema.
3. Independencia de los datos: El DBMS crea un ambiente en el que la
independencia de los datos puede mantenerse, por lo que la programación
y mantenimiento se disminuye sustancialmente.
4. Integridad de la base de datos. Dada la relación padre/hijo, siempre hay un
vínculo entre el segmento padre/hijo, por esto la integridad es promovida.
5. Eficiencia: Este modelo es eficiente cuando contiene un gran volumen de
datos en relaciones 1:M y cuando los usuarios requieren muchas
transacciones en las que utilizan datos cuyas relaciones se mantienen fijas
con el tiempo.

Desventajas del modelo Jerárquico.

Aunque las bases jerárquicas y sus aplicaciones aún existen, éste modelo
dejo de ser el ideal entre los añ6s 70’s y 80’s debido a las siguientes desventajas:

1. Difícil de administrador: Cualquier cambio en la estructura de la base de

datos requiere un cambio en todos los programas de aplicación que tiene
acceso a la base de datos, por lo que la administración puede convertirse
en una tarea muy difícil.
2. Dependencia de la estructura: Este modelo requiere de la navegación
entre los registros, por lo que el hacer alguna modificación requiere que el
programador conozca las rutas de navegación de cada regIstro.
3. Complejidad de la programación: La estrucura de la base de datos hace
muy compleja la programación, se dice que este modelo de base de datos
fue creado para programadores y por programadores.
4. Limitaciones de ejecución: Muchas relaciones no se ajustan al estándar
1:M requerido por el modelo jerárquico.

Ramírez,Marique
47
 Apuntes Docentes Base de datos I

5. Falta de estandarización: Este modelo no logro adoptar a manejadores

de base de datos que ofrecieran las herramientas necesarias por lo que
había diversas aplicaciones que se utilizaron para implementar este modelo
de base de datos.

En los años 70’s los profesionales de base de datos se reunieron y

publicaron un conjunto de estándares de base de datos que finalmente llevaron al
desarrollo de modelos alternos. El más notables fue el modelo de base de datos
de red.

4.2. Modelo de base de datos de red.

Las estructuras y construcciones del lenguaje para el modelo de red fueron

definidas por el comité CODASYL (Conference on Data Systems Languages:
Conferencia sobre lenguajes para sistemas de datos), posteriormente, el ANSI
(American National Standards Institute: Instituto nacional de estándares) publicó
una recomendación para el lenguaje de definición de red.

Los conceptos utilizados en el modelo de red son los siguientes:

Red : Conjunto de puntos intercalados de alguna forma.

Arista : la conexión entre dos puntos se denomina arista. Consiste en una serie
de registros que están conectados entre sí por medio de ligas. Una arista coincide
con un punto si lo toca.
Grado de un nodo: Es el número de aristas que inciden en él.
Conjunto : El bloque básico de construcción de una red.
Registro propietario: Al tipo de registro en el "lado uno" de la relación "uno a
muchos" se le denomina tipo de registro propietario.
Registro miembro: A el registro en el lado "muchos" se le denomina registro
miembro.
Esquema: La vista lógica de todos los datos y sus interrelaciones en la
base de datos.
Subesquemas: Los subconjuntos del esquema que se definen por la vista del
usuario de la base de datos.

Los sistemas de base de datos de red son similares a los sistema

jerárquicos. Una de las mayores diferencias es que, bajo ciertas condiciones un
hijo puede tener más de un padre, en el modelo de red.

La base de datos se compone de una colección de conjuntos.

Ventajas del modelo.

Este modelo conserva ventajas del modelo jerárquico y al mismo tiempo

tener algunas mejoras, las ventajas de este modelo son:

Ramírez,Marique
48
 Apuntes Docentes Base de datos I

1. Simplicidad conceptual: La vista conceptual de la base es simple y por lo

tanto simplifica el diseño.
2. Maneja más tipos de relaciones: Las relaciones M:M son más fáciles de
manejar en una base de este tipo ya que la posibilidad de establecer
relaciones de diversa índole son posibles, creación de lazos en las
relaciones.
3. Flexibilidad de acceso a los datos: Una aplicación puede tener acceso a
un registro propietario y a todos los registros miembros dentro de un
conjunto. Si un registro miembro tiene dos o más propietarios puede
pasarse de un propietario a otro.
4. Independencia de datos: Este modelo aisla parcialmente los programas
de los detalles de almacenamiento físico complejo.
5. Estandarización: Este modelo surge con la creación de estándares, por lo
que la estandarización en este modelo es una ventaja.

Desventajas del modelo.

Aún cuando este modelo ofrecía ventajas en comparación al modelo

jerárquico, estaba sujeto a desventajas significativas:

1. Complejidad interna: Este modelo no fue creado para tener accesos

sencillos, es necesario que el programador conociera claramente las rutas
de navegación de los registros para que fuese posible su manipulación y
actualización.
2. Falta de independencia estructural: Algunos cambios estructurales son
imposibles de hacer, al realizar algún cambio, es necesario modificar todas
las aplicaciones.

4.3. Modelo Relacional.

Se basa en la utilización de tablas, están formadas por renglones (tuplas) y

columnas (atributos). Anteriormente ya se analizó este modelo de base de datos.

4.4. Sistema de base de datos distribuida.

Concepto base de datos distribuida.

Base de datos segmentada ubicada en distintas localizaciones unidas

todas ellas através de una red.
El procesamiento de base de datos distribuidas actualmente se encuentra
en evolución y cambios, no es posible hablar de una disciplina que se encuentre

Ramírez,Marique
49
 Apuntes Docentes Base de datos I

totalmente establecida o madura, actualmente se realizan diversos algoritmos de

control de concurrencias y varios de ellos se encuentran en la fase de
implementación, al igual que en la de corrección.

Sistema de base de datos distribuida.

Una colección de localidades, en cada una de las cuales opera un sistema

de base de datos local y que pueden participar en la ejecución de transacciones
que acceden datos de varias localidades.

Datos locales.
Datos en mismo sitio o localidad con su propia base de datos.
Datos globales.
Datos que se mantienen en una base de datos cuya ubicación es diferente
para al menos uno de los usuarios.
Enlace.
Canales de comunicación entre dos sitios de la red y que proveen las
capacidades de transferencia de datos.
Sistema de gestión de base de datos distribuida (SGBDD).
Software que gestiona el sistema de base de datos distribuidas.
Transacción.
La ejecución de un programa de usuario que interactúa con el
SGBDD.
Transacción local.
Una transacción que requiere un único agente.
Transacción global.
Una transacción que requiere varios agentes.
Manejadores de base de datos distribuidas.
 System for distributed databases (SSD)
 R* Un SGBDD comercializado por IBM.
 Distributed INGRESS. Un SGBDD comercializado por Relational
Technology.

En un sistema de B.D. distribuida, en el cual la base de datos misma está

distribuida. Una porción de la base de datos está almacenada en X cantidad de
computadoras y son procesadas tanto aplicaciones como la base de datos

4.5. Sistema de base de datos orientado a objetos.

La contribución de la programación orientada a objetos (OOP), al

desarrollo de los SGBDO es considerable. Se han desarrollado sistemas
manejadores de base de datos orientado a objetos, como el caso de SGBDO
Gemstone, que intenta extender las capacidades de un lenuaje OOP para
incluirle las capacidades de gestión de datos de los SGBD.
Los SGBDOs combinan capacidades de los lenguajes de OOP con las
funciones de almacenamiento de los SGBD tradicionales.

Ramírez,Marique
50
 Apuntes Docentes Base de datos I

Un sistema de base de datos que pueden implementar modelos

conceptuales directamente y que pueden representar complejidades que van
más alla de las capacidades de los sistemas relacionales.

Los conceptos utilizados en el modelo orientado a objetos son:

Clase.
Una representación abstracta (plantilla) de un conjunto de objetos.
Clase derivada.
Una clase que hereda características de otra clase.
Objeto complejo.
Corresponde a un agregado o interrelación de alto nível.

Ramírez,Marique
51
 Apuntes Docentes Base de datos I

5.1. Desarrollo del Diseño de una Base de Datos Relacional.

A continuación se muestra la resolución de un caso práctico, mostrándo

paso a paso cada una de las técnicas que se utilizan en el diseño de una base
de datos del modelo relacional, para la realización del caso utilizaré el formato
de un cheque de pago de sueldos.

Considere el formato de un Cheque o recibo de percepciones.

Un formato contiene las siguientes partes o componentes.

La certificación: Esta compuesta por información que certifica la

existencia y validez de la forma en éste caso el texto “ Liquidación de Sueldos
UABC ”.

Esta área del documento realmente no es relevante para el diseño de la

base de datos, sin embargo se considera como parte de la información.
.
La parte extencional : Que está conformada por un conjunto de campos
que son llenados en la generación de la forma. es éste caso (Empleado,
categoría, nombre, etc.)

La parte Intencional. Que está conformado por un conjunto implícito o

explícito de referencia a los nombres de los campos. Ejemplo (Percepciones,
deducciones, días, devengado, Ispt, etc.).

Parte descriptiva. Contiene instrucciones o reglas que deben ser

seguidas para llenar los campos de la parte extencional. En éste caso no se
tiene parte descriptiva.

A continuación definiremos las áreas y subáreas de la forma

seleccionada (cheque) identificando la parte intencional y extencional de la
forma.

Se identifican las siguientes áreas. datos relacionados con la

escuela, con el Profesor, datos de municipios, datos de movimientos los cuales
se subdividen en percepciones y deducciones, datos propios del cheque.

En seguida se construirá un árbol con las áreas encontradas en la forma,

en donde el nombre de la raíz es el nombre del documento y se definen todas
las áreas que conforman dicho documento.

Ramírez,Marique
52
 Apuntes Docentes Base de datos I

Figura No.23 árbol de áreas o entidades.

Cada tabla se revisa para identificar, si es necesario subdividir en otras

áreas, alguna de las tablas determinadas, encontrándose que la tabla
movimiento puede subdividirse en 2 subáreas percepciones y deducciones.

Como resultado obtenemos el árbol anteriormente descrito, en el que se

muestran gráficamente cada una de las áreas y subáreas identificadas.

Por cada una de las áreas identificadas se genera una entidad. Por lo
tanto las entidades hasta ahora serán :

Entidad municipio, escuela, profesor, movimiento, cheque.

Municipio

Escuela

Profesor

Movimiento

Cheque

Figura 24 Areas convertidas a Entidad.

Cada entidad debe ser relacionada con algunas entidades para dar
sentido y aplicación a la forma, esto es determinar a que escuela pertenece un
profesor, a que municipio pertenece una escuela, etc.

Ramírez,Marique
53
 Apuntes Docentes Base de datos I

Enseguida se determinarán las relaciones que deben existir entre cada

entidad.

Fig. 25. Diagrama esqueleto para la forma de cheque.

En el diagrama anterior se definen las relaciones que existen entre cada

una de las entidades. Un cheque es envíado a un municipio al igual que a
determinada escuela, un cheque es entregado a un profesor. Cada profesor
puede tener diversos movimientos (percepciones, deducciones).

A partir del diagrama esqueleto anterior se contínua con el refinamiento.

Por cada área y subárea es necesario convertirla a generalización,
identificamos a una de las áreas es necesario clasificarla nuevamente
movimientos en deducciones y percepciones, obteniendo el siguiente diagrama.

Ramírez,Marique
54
 Apuntes Docentes Base de datos I

Fig 26. Diagrama Refinado con generalización de la forma de cheque.

A cada entidad creada es necesario colocar atributos correspondientes

de acuerdo a la forma.

Entidad Cheque:
Atributos
• No-cheque
• Fecha , el cual es un dato compuesto por día, mes, año.

Entidad Municipio:
Atributos
• Nombre del municipio.
• Número de empleado.
• Nombre profesor.
• Categoría.

Entidad Movimientos:
Atributos
• Número de movimiento.
• Monto del movimiento (Monto-mov es un dato de relación entre profesor y
movimientos).

Entidad Escuela:

Ramírez,Marique
55
 Apuntes Docentes Base de datos I

Atributos
• Número de escuela.
• Nombre de la escuela.

Entidad Empleado:
Atributos
• Número de empleado.
• Nombre profesor.
• Categoría del profesor.

El siguiente paso es reconocer los identificadores para cada entidad.

Entidad Identificador

Cheque Número de cheque.

Municipio Debido a que municipio no tiene un

identificador es necesario crear uno, en éste
caso Número de municipio.

Escuela Clave de la escuela.

Profesor Número de empleado.

Movimientos Clave del movimiento.

En está entidad es necesario agregar el
campo nombre de movimiento.

A partir de éste momento el identificador de una tabla se reconocerá con

el carácter •.

En seguida se muestra el Diagrama Entidad-Relación que ha sido

generado, como resultado de éste diseño.

Ramírez,Marique
56
 Apuntes Docentes Base de datos I

Fig. 27 Diagrama Entidad-Relación

En el diagrama Entidad-Relación es posible visualizar la cardinalidad de

cada una de las relaciones, enseguida se mostrará una tabla en la que se
específica, cada entidad y la cardinalidad existente.

Entidad
Cheque Profesor

Profesor Cheque

Profesor Movimientos

Movimientos Profesor

Mínima
1 Porque cada maestro tiene por lo menos un cheque.
1 porque al menos a un maestro se le paga con cheque.
1 porque al menos 1 maestro tiene movimientos en su cheque.
1 Por lo menos se tiene 1 movimiento por maestro.

Máxima

Ramírez,Marique
57
 Apuntes Docentes Base de datos I

M Porque el número de cheques va en relación directa con el número de

empleados.
M Porque 1 maestro puede recibir hasta M cheques.
M porque cada maestro tiene M cantidad de movimientos.
M porque se tienen diversos movimientos para muchos maestros.

Municipio Cheques
Cheques Municipio
Cheques Escuela
Escuela Cheques

1 Por lo menos se envían los cheques a un municipio.

1 Por lo menos se envía un cheque a un municipio.
1 Por lo menos se envía un cheque a una escuela.
1 Por lo menos se envían los cheques a una escuela.
M porque a cada municipio se envían m cantidad de cheques.
M porque los cheques son envíados a diferentes municipios.
M porque son varios los cheques que se envían a escuelas.
M porque son varias escuelas las que reciben los cheques.

Cabe mencionar que la cardinalidad es representada como cardinalidad

máxima y cardinalidad mínima.

Cardinalidad máxima. Representa la cantidad máxima de entidades que

pueden participar en una relación.

Cardinalidad mínima. Cantidad mínima de entidades que participan en

la relación.

Una vez que se ha definido la cardinalidad y se tiene ya el diagrama

Entidad-Relación, éste debe ser convertido a tablas, por cada entidad que se
tiene se generará una tabla utilizando el siguiente formato.

Nombre de la tabla (Nombre de atributos)

Cheques (No_cheque, día, mes, año).

En está tabla existe un dato compuesto, como lo es la fecha, que está

conformada por día, mes año, debido a que una afinidad no debe tener este
tipo de campos, todos deben ser valores únicos, es necesario convertirlo a
atributos simples,como son en día, el mes, el año.

Profesor (No_emp, categoría, nombre).

En está tabla nos encontramos con el atributo categoría, mismo que

puede guardar diversos valores, por lo que se crea una nueva entidad con los
atributos clave-categoría, descripción de la categoría. Además se creará una
tabla de relación entre profesor y categoría.

Ramírez,Marique
58
 Apuntes Docentes Base de datos I

Categoría ( clave-categoría, descripción_cat)

Municipio (No-municipio, nombre_municipio)

Escuela (Clave-esc, nombre-esc)

En la entidad movimientos se tienen se tiene generalización y esto no es

posible implementarlo como tabla, por lo que es necesario crear dos tablas con
los mismos atributos.

Percepciones (Clave-per, nombre_per)

Deducciones (Clave-ded, nombre_ded)

Convertir relaciones a tablas.

Por cada relación se crea una tabla, se coloca la llave de las dos
entidades que participan. Si la relación tuviése atributos, se agregan a la tabla
de relación recién creada.

Cheque_maestro (No-cheque, no_emp)

Para seleccionar la clave, se elige el campo clave de la entidad fuerte,

según la cardinalidad, esto es la clave que tiene la relación 1.

Cheques_municipio (No-cheque, No_municipio)

Cheque_escuela (No-cheque, No_escuela)

Profesor_Percepciones (No-emp, clave-perc, monto-perc)

Profesor_Deducciones (No-emp, clave-deduc, monto-deduc)

El siguiente paso es determinar que la base de datos se encuentra

normalizada.

Se encuentra en Tercera forma normal debido a que el campo clave de

cada una de las tablas define funcionalmente a cada uno de los atributos de las
tablas. Por lo que toda la base se encuentra en Tercera forma normal.

Ramírez,Marique
59
 Apuntes Docentes Base de datos I

1. Listar el catálogo de profesores.

Select No-emp, nombre from profesor.

2. Determinar que maestros pertenecen a la escuela.

Select No-emp, nombre from profesor where No-cheque = (Select
no_cheque from cheque_escuela where no-escuela = x)

3. Determinar categoría a la que pertenece x maestro.

Select categoría from profesor where no-emp = (Select no-emp from
profesor where nombre= nom)

4. Determinar percepciones que tiene un maestro.

Select no-emp, clave-perc from profesor -percepciones where no-emp =x
.
5. Determinar cuántos cheques recibe una escuela.
Select count (no-cheque) from cheque-escuela.
 Apuntes Docentes Base de datos I

Bibliografía.

1. Sistemas de Bases de Datos, Diseño, Implementación y Administración,

Peter Rob, Carlos Coronel, Edit. Thomson, 2004.
2. Diseño y Administración de Base de datos. Gary W. Hansen, James V.
Hansen. Prentice Hall. 2da. Edición.1998
3. Fundamentos de Base de Datos. Henry F. Korth, Abraham Silberschatz, Mc
Graw Hill, Quinta edic. 2006.
4. 2779B. Implementing a Microsoft SQL Server 2005 Database, Microsoft 2007
5. Sistemas de Base de Datos Conceptos Fundamentales. Elmasri/ Navathe.
Addison Wesley. 2da. Edición. 1997.
6. Introducción a los Sistemas de Bases de datos, C.J. Date, Prentice Hall,
Séptima Edición, 2001.
7. Aplique SQL James R. Groff, Paul N. Weinberg, Mc Graw Hill, 2da. edic
1998.