Está en la página 1de 21

UNIVERSIDAD ALEJANDRO DE HUMBOLDT.

FACULTAD DE INGENIERÍA.
INGENIERÍA INFORMÁTICA.

BASES DE DATOS

Autor: Michelle Lozano.


C.I: 27.047.963.

Caracas, marzo, 2019.


ÍNDICE GENERAL
ÍNDICE GENERAL ii
INTRODUCCIÒN 1

CAPITULOS

I HISTORIA 3
1950 3
1960 3
1970 4
1990 4
Siglo XXI 4

II SISTEMA DE GESTION DE BASES DE DATOS 5

III MODELOS DE DATOS 7


Modelo Conceptual 8
Modelo Lógico 8
Modelo Físico 8
Modelos Conceptuales 9
Modelos Entidad-Relación 9
Modelo Relacional 10

IV LENGUAJE SQL 10
Creación y Borrado de una Base de Datos Relacional 10
Creación de Tablas 12
Tipos de Datos 12

V CUESTIONES 13

VI CONCLUSIONES 18

REFERENCIAS 19

ii
INTRODUCCIÓN

Las bases de datos se encuentran hoy día, en casi cualquier aspecto de la vida, desde llevar
la organización del hogar, hasta almacenar la información inventariada de una empresa. Por
consiguiente se hace necesidad definir en principio lo que son bases de datos, enfocados en
el área informática. Los SGBD o Sistemas Gestores de Base de Datos, también conocido por
sus siglas en inglés DBMS (Data Base Management System), son programas creados para
almacenar datos de manera más rápida y autónoma, de modo que el usuario pueda acceder a
la información almacenada directamente.

En ese orden, los datos no son más que los hechos que describen sucesos que se pueden
ordenar y reordenar de forma utilizable y se les denomina información. Sin embargo no hay
que confundir el orden de las especificaciones, ya que los datos no contienen información,
contienen símbolos que describen condiciones, para que posteriormente el usuario cree la
información recompilada de los datos. Por si mismos los datos no tienen capacidad de
comunicar un significado y por tanto no pueden afectar el comportamiento de quien los
recibe. Para ser útiles, los datos deben convertirse en información para ofrecer un significado,
conocimiento, ideas o conclusiones.

De tal modo, se dice entonces que la información es una colección de hechos


significativos y relevantes para el organismo u organización, que los percibe. Para poseer una
significación, los datos deben constar de símbolos reconocibles, estar completos y expresar
una idea no ambigua. Los símbolos de los datos son reconocibles cuando pueden ser
correctamente interpretados. Tenemos que conocer el contexto de estos símbolos antes de
poder conocer su significado.

Capitulo I. Historia: en este capítulo se presenta un poco del origen del tema y su
influencia en el mundo, de manera que se contextualice.

Capitulo II. Sistema de Gestión de Base de Datos: en esta parte se describen los SGBD,
sus características y parte de su utilización.

Capitulo III. Modelos de Datos: en esta sección se describen los diferentes modelos de
datos implementados en los SBGD Y DB.

1
Capítulo IV. Lenguaje SQL: se define y describe más a fondo el principal lenguaje de
base de datos, el cual es el lenguaje SQL.

Capítulo V. Cuestiones: se realizan unos ejemplares de cómo sería una base de datos en
su respectivo lenguaje de programación.

Capítulo VI. Conclusiones: se definen las conclusiones en general de todo el tema


realizado.

2
CAPÍTULO I

HISTORIA

Los antecesores de los sistemas de bases de datos fueron los ficheros, aunque no hay un
momento exacto en la historia en la que los sistemas de ficheros hayan cesado. De hecho,
todavía existen sistemas de ficheros en uso. El uso de sistemas de bases de datos
automatizadas, se desarrolló a partir de la necesidad de almacenar grandes cantidades de
datos para su posterior consulta, producidas por las nuevas industrias que generaban gran
cantidad de información. Herman Hollerit (1860-1929) fue denominado el primer ingeniero
estadístico de la historia, ya que invento una computadora llamada Máquina Automática
Perforadora de Tarjetas.

Para hacer el censo de Estados Unidos en 1880 se tardaron 7 años para obtener resultados,
pero Herman Hollerit en 1884 creó la máquina perforadora. Con la cual, en el censo de 1890
dio resultados en 2 años y medio, donde se podía obtener datos importantes como número de
nacimientos, población infantil y número de familias. La máquina usó sistemas mecánicos
para procesar los datos de las tarjetas y para tabular los resultados. Este invento disparó el
desarrollo de la tecnología, abriendo así nuevas perspectivas y posibilidades hacia el futuro.

1.1. 1950.

En este lapso de tiempo se da origen a las cintas magnéticas, las cuales sirvieron para
suplir las necesidades de datos de las nuevas industrias. Por medio de este mecanismo se
empezó a automatizar los datos de las nóminas, como por ejemplo el aumento de salario.
Consistía en leer una cinta o más y pasar los datos a otra, y también se podían pasar desde
las tarjetas perforadas.

1.2. 1960.

El uso de los discos en ese momento fue un adelanto muy efectivo, ya que por medio de
éste soporte se podía consultar los datos directamente, esto ayudó a ahorrar tiempo. No era
necesario saber exactamente donde estaban los datos en los discos, ya que en milisegundos
eran recuperables los datos. A diferencia de las cintas magnéticas, ya no era necesaria la

3
secuencialidad. Los discos dieron inicio a las Bases de Datos, de red y jerárquicas, pues era
posible guardar estructuras de datos como listas y árboles.

1.3. 1970.

Edgar Frank Codd (1923 –2003), en un artículo “Un modelo relacional de datos para
grandes bancos de datos compartidos” (A Relational Model of Data for Large Shared Data
Banks) en 1970, definió el modelo relacional y publicó una serie de reglas para la evaluación
de administradores de sistemas de datos relacionales. A partir de los aportes de Codd el
multimillonario Larry Ellison desarrolló la base de datos Oracle, el cual es un sistema de
administración de base de datos, que se destaca por sus transacciones, estabilidad,
escalabilidad y multiplataforma. Inicialmente no se usó el modelo relacional debido a que
tenía inconvenientes por el rendimiento, ya que no podían ser competitivas con las bases de
datos jerárquicas y de red.

1.4. 1990.

Para la toma de decisiones se crea el lenguaje SQL, que es un lenguaje programado para
consultas. El programa de alto nivel SQL es un lenguaje de consulta estructurado que analiza
grandes cantidades de datos, el cual permite especificar diversos tipos de operaciones frente
a los mismos datos a diferencia de las bases de datos de los 80 que eran diseñadas para las
aplicaciones de procesamiento de transacciones. Los grandes distribuidores de bases de datos
incursionaron con la venta de bases de datos orientada a objetos.

Para finales de la década de los 90 aparece la WWW “Word Wide WebM, por éste medio
se facilitaba la consulta de las bases de datos. Actualmente tienen una amplia capacidad de
almacenamiento de información, también una de las ventajas es el servicio de siete días a la
semana las veinticuatro horas del día, sin interrupciones a menos que haya planificaciones
de mantenimiento de las plataformas o el software.

1.5. Siglo XXI.

En la actualidad existe gran cantidad de alternativas en línea que permiten hacer


búsquedas orientadas a necesidades específicas de los usuarios, una de las tendencias más
amplias son las bases de datos que cumplan con el protocolo Open Archives Initiative –

4
Protocol for Metadata Harvesting (OAI-PMH) los cuales permiten el almacenamiento de
gran cantidad de artículos que permiten una mayor visibilidad y acceso en el ámbito científico
y general. Como respuesta a la creciente complejidad de las aplicaciones que requieren bases
de datos, han surgido dos nuevos modelos: el modelo de datos orientado a objetos y el modelo
relacional extendido. Sin embargo, a diferencia de los modelos que los preceden, la
composición de estos modelos no está clara. Esta evolución representa la tercera generación
de los DBMS.

CAPITULO II

SISTEMA DE GESTIÓN DE BASE DE DATOS

Millán, M. (2017) en su texto Fundamentos de Bases de datos, expresa que “Un sistema
de gestión de bases de datos (SGBD) es una capa de software necesaria para crear, manipular
y recuperar datos desde una base de datos.” (p. 19). Al mismo tiempo plantea “Este principio
de independencia de datos hace posible que el administrador de la BD cambie la estructura
física de la BD (nivel interno) sin que la manera en la cual los diferentes usuarios ven los
datos (nivel externo) se afecte.”(p. 19).

De manera semejante, Camps Paré, R. y Col. (2005) para sus postgrado de la Universitat
Oberta de Catalunya, en su trabajo publicado como Software libre, habían definido a las
bases de datos de manera que:

Las bases de datos son el método preferido para el almacenamiento


estructurado de datos. Desde las grandes aplicaciones multiusuario, hasta los
teléfonos móviles y las agendas electrónicas utilizan tecnología de bases de datos
para asegurar la integridad de los datos y facilitar la labor tanto de usuarios como
de los programadores que las desarrollaron. (Camps Paré, R. y Col. 2005, p. 5)

Con la llegada de nuevas tecnologías se necesitaba almacenar cada vez más contenido,
que posteriormente debía ser consultado. De este modo llegó un sistema online en donde se
podían almacenar los datos y al mismo tiempo revisarlos, conectados a través de la red.
Camps Paré, R. y Col. (2005) lo plantearon tal que:

5
Estos conjuntos de ficheros interrelacionados, con estructuras complejas y
compartidos por varios procesos de forma simultánea (unos on-line y otros por
lotes), recibieron al principio el nombre de Data Banks, y después, a inicios de
los años setenta, el de Data Bases. (Camps Paré, R. y Col. 2005, p. 7)

Según Gómez (2007) una base de datos es un conjunto de datos que pertenecen al mismo
contexto, almacenados sistemáticamente para su posterior uso, es una colección de datos
estructurados según un modelo que refleje las relaciones y restricciones existentes en el
mundo real. Los datos que han de ser compartidos por diferentes usuarios y aplicaciones,
deben mantenerse independientes de éstas, y su definición y descripción han de ser únicas
estando almacenadas junto a los mismos. (p. 18)

Por otro lado Juárez (2006) dice que una base de datos es un conjunto de datos
almacenados entre los que existen relaciones lógicas y que ha sido diseñada para satisfacer
los requerimientos de información de una empresa u organización. (p.45)

Lo anterior conduce a que, las bases de datos son un conjunto de información relacionada
no redundante que está organizada, sistematizada y que debe encauzarse en un propósito
específico de una comunidad. Del mismo modo tiene que cumplir con los objetivos de
independencia, integridad y la seguridad de datos ante los múltiples usuarios que la utilicen,
debido a que cualquier tipo de datos que se utiliza en una base, es de fundamental importancia
que no sufra cambios por usuarios que no están debidamente acreditados para hacerlos.

Aparte de las reglas de integridad que el diseñador de la BD puede definir y


que el SGBD entenderá y hará cumplir, el mismo SGBD tiene reglas de
integridad inherentes al modelo de datos que utiliza y que siempre se cumplirán.
Son las denominadas reglas de integridad del modelo. Las reglas definibles por
parte del usuario son las reglas de integridad del usuario. El concepto de
integridad de los datos va más allá de prevenir que los programas usuarios
almacenen datos incorrectos. En casos de errores o desastres, también podríamos
perder la integridad de los datos. El SGBD nos debe dar las herramientas para
reconstruir o restaurar los datos estropeados. (Camps Paré, R. y Col. 2005, p. 28)

6
CAPITULO III

MODELOS DE DATOS

Intuitivamente, las relaciones se asocian con tablas nombradas cuyas


columnas representan atributos que también pueden tener asociado un nombre.
Las filas de las tablas son tuplas. Los valores que toman las tuplas se extraen de
conjuntos de constantes llamados dominios. Todas las tablas constituyen la
estructura de la base de datos que se representa en un esquema de base de datos
(nivel intencional) y su contenido en una instancia de base de datos (nivel
extensional). (Millán, M. 2017, p. 25)

La abstracción de datos es un nivel característico en una base de datos, ya que es


fundamental que los usuarios solo conozcan los datos que le son útiles y no todas las
características sobre el almacenamiento físico. Es importante identificar que un modelo es
una representación de la realidad que contiene las características generales de algo que se va
a realizar.

Según Navarro (2009) “un modelo de datos es una colección de herramientas conceptuales
para describir los datos, las relaciones que existen entre ellos, semántica asociada a los datos
y restricciones de consistencia.”(p.16)

Un modelo de datos es un conjunto de conceptos que sirven para describir la


estructura de una base de datos: los datos, las relaciones entre datos y las
restricciones que deben cumplirse sobre los datos. Los modelos de datos
contienen también un conjunto de operaciones básicas para la realización de
consultas y actualizaciones de datos. (Estrada. 2005, p.47)

Los modelos de datos se pueden clasificar dependiendo de los tipos de conceptos que
ofrecen para describir la estructura de la base de datos. Juárez (2006, p.56) plantea la
existencia de tres modelos dentro de una base de datos estos son:

7
3.1. Modelo conceptual.

En este se construye un esquema conceptual de la información que se usara en la base de


datos, al construir este esquema, se descubre el significado de los datos, se encuentran
entidades, atributos y relaciones. En este modelo se tiene como objetivo comprender:

 La perspectiva que el usuario tiene de los datos


 La naturaleza de los datos, independientemente de su representación física

El esquema conceptual se construye utilizando la información que se encuentra en la


especificación de los requisitos del usuario. El modelo conceptual es completamente
independiente de los aspectos de implementación, como pueden ser los programas de
aplicación, los lenguajes de programación, etc. En este modelo siempre se valida que los
requisitos del usuario se cumplan de manera satisfactoria.

3.2. Modelo lógico.

Este modelo es una fuente de información para el diseño físico, transformando al esquema
obtenido en el modelo conceptual. El avance de este modelo depende de la evolución que se
obtiene al desarrollar, probar y validar los requisitos del usuario. Este modelo es de
fundamental importancia en la etapa del mantenimiento del sistema, ya que permite que los
futuros cambios que se realicen en los programas de aplicación o sobre los datos, se
representen correctamente en la base de datos.

3.3. Modelo físico.

En éste se produce 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. Es fundamental que se tenga un buen diseño del modelo lógico, debido
a que entre el diseño físico y el lógico existe una realimentación, ya que algunas de las
decisiones que se toman durante el diseño físico, pueden afectar a la estructura del modelo
lógico.

El objetivo del modelo físico es describir cómo se va a implementar físicamente el


esquema formado en el modelo conceptual y lógico, dicha implementación consiste en:

8
 Obtener un conjunto de relaciones 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.

Los distintos modelos se dirigen a usuarios diferentes, por ejemplo los conceptos de los
modelos físicos están dirigidos al personal informático y no a los usuarios finales como es el
caso de los modelos lógicos.

3.4. Modelos conceptuales.

Según Navarro (2009) se usan para describir datos, es decir con este modelos se
representan los datos tal y como se captan del mundo real, tiene la capacidad de
estructuración bastante flexible y permiten especificar restricciones de datos explícitamente.
(p. 16)

Existen diferentes modelos de este tipo, pero el más utilizado por su sencillez y eficiencia
es el modelo Entidad-Relación.

3.5. Modelo Entidad-Relación.

Según Sánchez (2004) “fue creado por Peter Chen en los años 1976 y 1977 a través de
dos artículos. Se trata de un modelo que sirve para crear esquemas conceptuales de bases de
datos, es un estándar para crear dichos esquemas.” (p. 17)

El modelo de datos Entidad –Relación (E-R) está basado en una percepción


del mundo real que consta de una colección de objetos básicos como entidades y
relaciones, mediante un diagrama E-R se puede expresar gráficamente la
estructura lógica general de una base de datos. El diagrama entidad relación
consta de diversos componentes como entidades, atributos, relaciones entre
conjuntos de entidades, unión de atributos con los conjuntos de entidades y/o
relaciones, etcétera. (Silberschatz, 2002, p. 5)

9
Cada componente siempre se señala con la etiqueta o relación que representa. En un
modelo E-R además de entidades y relaciones, representa ciertas restricciones que los
contenidos de la base de datos deben cumplir. Una restricción importante es la
correspondencia de cardinalidades, misma que expresa el número de entidades con las que
otra entidad se puede asociar a través de un conjunto de relaciones.

3.6. Modelo relacional.

Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar


datos dinámicamente. Su idea fundamental es el uso de “relaciones”, las cuales podrían
considerarse en forma lógica como tuplas mismas que a su vez son un conjunto de datos.

En este modelo se representan los datos y las relaciones entre estos, a través
de una colección de tablas, en las cuales los renglones (tuplas) equivalen a cada
uno de los registros que contendrá la base de datos y las columnas corresponden
a las características (atributos) de cada registro localizado en la tupla. (Navarro,
2009, p. 18)

CAPITULO IV

LENGUAJE SQL

4.1. Creación y borrado de una base de datos relacional.

El SQL es el lenguaje estándar ANSI/ISO de definición, manipulación y control de bases


de datos relacionales. Es un lenguaje declarativo: sólo hay que indicar qué se quiere hacer.
En cambio, en los lenguajes procedimentales es necesario especificar cómo hay que hacer
cualquier acción sobre la base de datos. El SQL es un lenguaje muy parecido al lenguaje
natural; concretamente, se parece al inglés, y es muy expresivo. Por estas razones, y como
lenguaje estándar, el SQL es un lenguaje con el que se puede acceder a todos los sistemas
relacionales comerciales. Escofet, C.M. y Col. (2005) “Con el SQL se puede definir,
manipular y controlar una base de datos relacional.” (p.114)

10
El estándar SQL92 no dispone de ninguna sentencia de creación de bases de
datos. La idea es que una base de datos no es más que un conjunto de tablas y,
por lo tanto, las sentencias que nos ofrece el SQL92 se concentran en la creación,
la modificación y el borrado de estas tablas. (Escofet, C.M. y Col. 2005, p. 120)

Muchos de los sistemas relacionales comerciales (como ocurre en el caso de Informix,


DB2, SQL Server y otros) han incorporado sentencias de creación de bases de datos con la
siguiente sintaxis: CREATE DATABASE

En cambio, si se dispone de una sentencia más potente que la de creación de bases de


datos: la sentencia de creación de esquemas denominada CREATE SCHEMA.

CREATE SCHEMA {[nombre_esquema]} | [AUTHORIZATION usuario]}


[lista_de_elementos_del_esquema];

La sentencia de creación de esquemas hace que varias tablas


(lista_de_elementos_del_esquema) se puedan agrupar bajo un mismo nombre
(nombre_esquema) y que tengan un propietario (usuario). Aunque todos los
parámetros de la sentencia CREATE SCHEMA son opcionales, como mínimo se
debe dar o bien el nombre del esquema, o bien el nombre del usuario propietario
de la base de datos. (Escofet, C.M. y Col. 2005, p. 120)

11
Para borrar una base de datos se encuentra el mismo problema que para crearla. El estándar
SQL92 sólo ofrece la sentencia de borrado de esquemas DROP SCHEMA, que presenta la
siguiente sintaxis:

DROP SCHEMA nombre_esquema {RESTRICT|CASCADE};

4.2. Creación de tablas.

CREATE TABLE nombre_tabla


(definición_columna
[, definición_columna...]
[, restricciones_tabla]
);

Donde definición_columna es:

nombre_columna {tipo_datos|dominio} [def_defecto] [restric_col]

4.3. Tipos de datos.

Tipos de datos Descripción


CHARACTER (longitud) Cadenas de caracteres de longitud fija.
CHARACTER VARYING (longitud) Cadenas de caracteres de longitud variable.

BIT (longitud) Cadenas de bits de longitud fija.


BIT VARYING (longitud) Cadenas de bits de longitud variables.
NUMERIC (precisión, escala) Número decimales con tantos dígitos como
indique la precisión y tantos decimales
como indique la escala.
DECIMAL (precisión, escala) Número decimales con tantos dígitos como
indique la precisión y tantos decimales
como indique la escala.
INTEGER Números enteros.

SMALLINT Números enteros pequeños.


REAL Números con coma flotante con precisión
predefinida.
FLOAT (precisión) Números con coma flotante con la precisión
especificada.
DOUBLE PRECISION Números con coma flotante con más
precisión predefinida que la del tipo REAL.

12
DATE Fechas. Están compuestas de: YEAR año,
MONTH mes, DAY día.
TIME Horas. Están compuestas de HOUR hora,
MINUT minutos, SECOND segundos.
TIMESTAMP Fechas y horas. Están compuestas de YEAR
año,
MONTH mes, DAY día, HOUR hora,
MINUT minutos, SECOND segundos.

CAPITULO V

CUESTIONES

1. Realiza el diseño físico para el siguiente modelo relacional. Asigna el tipo de datos
que consideres más adecuado. Realiza el diseño sin poner nombres a las
restricciones. Esquema E01, contraseña «E01».

SET SQLPROMPT "";


SET SQLNUMBER OFF;
CONNECT SYSTEM/SYSTEM
DROP USER E01 CASCADE;
CREATE USER E01 IDENTIFIED BY "E01";
GRANT CONNECT,RESOURCE TO E01;
CONNECT E01/E01;
CREATE TABLE ALUMNO
(
NUMMATRICULA NUMBER(3) PRIMARY KEY,
NOMBRE VARCHAR2(50),
FECHANACIMIENTO DATE,
TELEFONO CHAR(9)
);
CREATE TABLE PROFESOR
(
IDPROFESOR NUMBER(2) PRIMARY KEY,
NIF_P CHAR(9) UNIQUE,
NOMBRE VARCHAR2(50),

13
ESPECIALIDAD VARCHAR2(50),
TELEFONO CHAR(9)
);
CREATE TABLE ASIGNATURA
(
CODASIGNATURA CHAR(6) PRIMARY KEY,
NOMBRE VARCHAR2(30),
IDPROFESOR NUMBER(2) REFERENCES PROFESOR(IDPROFESOR)
);
CREATE TABLE RECIBE
(
NUMMATRICULA NUMBER(3) REFERENCES ALUMNO(NUMMATRICULA),
CODASIGNATURA CHAR(6) REFERENCES ASIGNATURA(CODASIGNATURA),
CURSOESCOLAR CHAR(9),
PRIMARY KEY (NUMMATRICULA, CODASIGNATURA, CURSOESCOLAR)
);

Nota: Observa el orden en el que creamos las tablas. Las tablas que contienen claves
foráneas deben crearse después de crear las tablas que contienen las claves primarias a las
que apuntan.

2. Realiza el diseño físico para el siguiente modelo relacional. Asigna el tipo de datos
que consideres más adecuado. Realiza el diseño sin poner nombres a las
restricciones. Esquema E02, contraseña «E02».

CREATE TABLE EMPLEADO


(
ID NUMBER(3),
DNI CHAR(9),
NOMBRE VARCHAR2(50),
FECHANAC DATE,
TELEFONO CHAR(9),
SALARIO NUMBER(6,2),
CODLOCALIDAD NUMBER(5),
PRIMARY KEY (ID),
UNIQUE (DNI),

14
FOREIGN KEY (CODLOCALIDAD) REFERENCES
LOCALIDAD(CODLOCALIDAD)
);

3. Realiza el diseño físico para el siguiente modelo relacional. Asigna el tipo de datos
que consideres más adecuado. Realiza el diseño sin poner nombres a las
restricciones. Esquema E10, contraseña «E10».

Crea las tablas sin restricciones y añádelas después con el comando ALTER TABLE. Crea
secuencias que inicien en 1 para: NumCliente, NumArtículo, NumFabrica y NumPedido.

SET SQLPROMPT "";


SET SQLNUMBER OFF;
CONNECT SYSTEM/SYSTEM;
DROP USER E10 CASCADE;
CREATE USER E10 IDENTIFIED BY "E10";
GRANT CONNECT,RESOURCE TO E10;
CONNECT E10/E10;
CREATE TABLE FABRICA
(
NUMFABRICA NUMBER(2),
TELEFONO CHAR(9)
);
ALTER TABLE FABRICA ADD CONSTRAINT PK_FABRICA
PRIMARY KEY(NUMFABRICA);
CREATE TABLE ARTICULO
(
NUMARTICULO NUMBER(5),

15
DESCRIPCION VARCHAR2(100)
);

ALTER TABLE ARTICULO ADD CONSTRAINT PK_ARTICULO


PRIMARY KEY(NUMARTICULO);
CREATE TABLE CLIENTE
(
NUMCLIENTE NUMBER(5),
SALDO NUMBER,
LIMCREDITO NUMBER(4),
DESCUENTO NUMBER(2)
);
ALTER TABLE CLIENTE ADD CONSTRAINT PK_CLIENTE
PRIMARY KEY(NUMCLIENTE);
CREATE TABLE DIRECCION
(
CODDIRECCION CHAR(8),
VIA VARCHAR2(20),
NOMBREVIA VARCHAR2(50),
NUMERO NUMBER(3),
PISO NUMBER(1),
PORTAL CHAR(1),
CODPOSTAL CHAR(5)
);
ALTER TABLE DIRECCION ADD CONSTRAINT PK_DIRECCION
PRIMARY KEY (CODDIRECCION);
CREATE TABLE PEDIDO
(
NUMPEDIDO NUMBER(5),
FECHA DATE,
NUMCLIENTE NUMBER(5),
CODDIRECCION CHAR(8)
);
ALTER TABLE PEDIDO ADD CONSTRAINT PK_PEDIDO
PRIMARY KEY (NUMPEDIDO);
ALTER TABLE PEDIDO ADD CONSTRAINT FK1_PEDIDO
FOREIGN KEY (NUMCLIENTE) REFERENCES CLIENTE(NUMCLIENTE);
ALTER TABLE PEDIDO ADD CONSTRAINT FK2_PEDIDO
FOREIGN KEY (CODDIRECCION) REFERENCES DIRECCION(CODDIRECCION);
CREATE SEQUENCE NUMCLIENTE;
CREATE SEQUENCE NUMPEDIDO;
CREATE SEQUENCE NUMARTICULO;
CREATE SEQUENCE NUMFABRICA;
CREATE TABLE POSEE

16
NUMCLIENTE NUMBER(5),
CODDIRECCION CHAR(8)
);
ALTER TABLE POSEE ADD CONSTRAINT PK_POSEE
PRIMARY KEY(NUMCLIENTE, CODDIRECCION);
ALTER TABLE POSEE ADD CONSTRAINT FK1_POSEE
FOREIGN KEY(NUMCLIENTE) REFERENCES CLIENTE(NUMCLIENTE);
ALTER TABLE POSEE ADD CONSTRAINT FK2_POSEE
FOREIGN KEY(CODDIRECCION) REFERENCES DIRECCION(CODDIRECCION);
CREATE TABLE INCLUYE
(
NUMPEDIDO NUMBER(5),
NUMARTICULO NUMBER(5),
CANTIDAD NUMBER(5)
);
ALTER TABLE INCLUYE ADD CONSTRAINT PK_INCLUYE
PRIMARY KEY(NUMPEDIDO,NUMARTICULO);
ALTER TABLE INCLUYE ADD CONSTRAINT FK1_INCLUYE
FOREIGN KEY(NUMPEDIDO) REFERENCES PEDIDO(NUMPEDIDO);
ALTER TABLE INCLUYE ADD CONSTRAINT FK2_INCLUYE
FOREIGN KEY(NUMARTICULO) REFERENCES ARTICULO(NUMARTICULO);
CREATE TABLE DISTRIBUYE
(
NUMFABRICA NUMBER(2),
NUMARTICULO NUMBER(5),
CANTSUMINISTRO NUMBER(5),
EXISTENCIAS NUMBER(5)
);
ALTER TABLE DISTRIBUYE ADD CONSTRAINT PK_DISTRIBUYE
PRIMARY KEY(NUMFABRICA,NUMARTICULO);
ALTER TABLE DISTRIBUYE ADD CONSTRAINT FK1_DISTRIBUYE
FOREIGN KEY(NUMFABRICA) REFERENCES FABRICA(NUMFABRICA);
ALTER TABLE DISTRIBUYE ADD CONSTRAINT FK2_DISTRIBUYE
FOREIGN KEY(NUMARTICULO) REFERENCES ARTICULO(NUMARTICULO);

17
CONCLUSIONES

Se ha podido explicar la evolución de los SGBD, que ha conducido de una estructura


centralizada y poco flexible a una distribuida y flexible, y de una utilización procedimental
que requería muchos conocimientos a un uso declarativo y sencillo. Es especialmente
importante el concepto de transacción y la forma en que se utiliza para velar por la integridad
de los datos. La arquitectura de tres niveles aporta una gran flexibilidad a los cambios, tanto
a los físicos como a los lógicos. Un SGBD puede funcionar utilizando los tres esquemas
propios de esta arquitectura. Los componentes de un modelo de BD son las estructuras, las
restricciones y las operaciones. Los diferentes modelos de BD se diferencian básicamente
por sus estructuras. Cada tipo de usuario del SGBD puede utilizar un lenguaje apropiado para
su trabajo. Unos usuarios con una tarea importante y difícil son los administradores de las
BD.

El SQL es un lenguaje muy potente, y esto hace que existan más sentencias y opciones de
las que se ha explicado en este trabajo. Así como también se ha intentado seguir con la mayor
fidelidad el estándar, incluyendo comentarios sólo cuando en la mayoría de los sistemas
relacionales comerciales alguna operación se hacía de forma distinta. Conociendo el SQL92
se puede trabajar con cualquier sistema relacional comercial; sólo se tendrá que dedicar unas
cuantas horas a ver qué variaciones se dan con respecto al estándar.

18
REFERENCIAS BIBLIOGRÁFICAS

Camps Paré, R. y Col.. (2005). Software Libre. 1ra. ed. Fundació per a la Universitat Oberta
de Catalunya
Millán, M. (2017). Fundamentos de bases de datos. Ed. Digital. Santiago de Cali: Programa
Editorial Universidad del Valle.
R. Elmasri, S.B. Navathe (1997). Sistemas de Bases de Datos. Conceptos fundamentales.
2da. ed. Addison-Wesley Iberoamericana.

19

También podría gustarte