Tutorial Oracle Este documento explica paso a paso el procedimiento para la realización de una base de datos en el motor de base de datos Oracle 1. Ejercicio Propuesto: Un centro de instalaciones deportivas quiere hacer una aplicación de reservas. En el centro existen instalaciones deportivas (piscinas, gimnasios, frontones, etc.). El centro en cuestión tiene socios, de los cuales se almacenan su dirección, ciudad, provincia, teléfono, nombre y estado. Existen una serie de artículos que se pueden alquilar junto con las reservas (balones, redes, raquetas, etc.). Cada instalación es reservada por un socio en una fecha dada desde una hora de inicio hasta una hora de fin siempre y cuando este al día en sus cuotas. Cada reserva puede tener asociada uno o varios artículos deportivos que se alquilan aparte. Por ejemplo si yo quiero hacer una reserva para jugar a voleibol tengo que reservar una instalación polideportivo más un artículo red, más un artículo balón. 1.1
Modelo Conceptual
El modelo conceptual es el primer paso en el camino de la realización de una base de datos, luego de saber cuáles son los datos y como es el funcionamiento de lo que se desea guardar en la base de datos se inicia con la identificación de entidades, partiendo de que una entidad es la representación de un objeto o concepto del mundo real que se describe en una base de datos del cual se recopilan, almacena y mantienen datos, ejemplo una persona, es un concepto de la vida real, del cual se le pueden recoger datos como nombre, edad, sexo, etc. Para nuestro caso las entidades resultantes serian: Instalación, Socio, Cuota, Reserva y Artículo. Luego de identificar y definir las entidades, pasamos a identificar los atributos, los atributos son las propiedades de las entidades, ejemplo de una entidad llamada carro, algunas de sus propiedades son la marca, el modelo, el color, etc. Para cada entidad se definen sus atributos: Instalación: Código, Descripción, Estado Socio: No_Identificacion, Nombre, Dirección, Teléfono, Ciudad, Provincia, Estado Artículo: Código, Descripción, Marca, Estado Cuota: Número, Estado, Monto, Fecha_Pago Reserva: Código, Fecha Una vez se han identificado los atributos para cada entidad, proseguimos a establecer las relaciones que ente estas se pueden dar, una relación es un vinculo que existe entre dos o más entidades que describe la interacción entre ellas.
Relación
Entidad
Entidad
Paga
Socio
Cuota
Hace
Socio
Reserva
Contiene
Reserva
Instalación Articulo
Estas relaciones se pueden interpretar como: Un socio Paga una Cuota Un socio Hace una reserva Una reserva Contiene una instalación y un Articulo Luego de esto definimos la cardinalidad de cada una de las relaciones. La cardinalidad nos define le tipo de relación que se da, estas pueden ser tres: Uno a Uno, Uno a muchos, y Muchos a Muchos. Y se interpretan en los dos sentidos de la relación: Un socio paga una o varias cuotas Una cuota es pagada por un solo socio Un socio hace una o varias reservas Una reserva es hecha por un socio Una reserva contiene una o varias instalaciones Una instalación puede estar en una o varias reservas Una instalación reservada puede contener uno o más artículos Un artículo puede estar incluido en una o más instalaciones reservadas Una vez definido los vínculos y el tipo de vínculo entre nuestras entidades, el siguiente paso es definir las restricciones, una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la base de datos, estas restringen los datos que pueden ser almacenados en una tabla y juegan el rol de organizar mejor los datos. Las restricciones pueden ser llaves primarias, son llaves foráneas, si los valores correspondientes a un atributo pueden ser nulos o vacios, o en caso contrario son obligatorios. La llave primaria es aquel atributo de una entidad que identifica a la entidad como tal, no se repite y ninguna otra entidad posee un dato igual, por ejemplo la cedula de la entidad persona es una clave primaria pues es única para cada registro, y no existen dos personas con un mismo número, como lo es también una huella que es única para cada persona. La llave foránea es una llave primaria de otra entidad, se utiliza para relacionar datos entre entidades, ejemplo cuando una persona es dueña de un carro, la entidad carro tiene sus propios atributos, de igual forma la entidad persona, la llave primaria de la persona la llevamos a la entidad caro para relacionar a quien pertenece el carro, la llave primaria de la entidad persona se convierte en una llave foránea en la entidad carro.
Por ahora definiremos las llaves primarias y valores obligatorios, las llaves foráneas las definiremos a la hora de pasar el modelo conceptual al modelo lógico.
Instalación:
Código Primary Key – not null Descripción not null Estado not null
Socio:
No_Identificacion Nombre Dirección Teléfono Ciudad Provincia Estado
Artículo:
Cuota:
Primary Key – not null not null not null not null not null null not null
Código Descripción Marca Estado
Primary Key – not null not null null not null
Número Estado Monto Fecha_Pago
Primary Key – not null not null not null not null
Reserva:
Código Fecha
1.2
Primary Key – not null null
Modelo Lógico
Hecho el modelo conceptual, lo pasamos al modelo lógico, la forma de hacerlo es muy fácil, siguiendo unas consideraciones: Cada entidad definida representa una tabla Cada atributo representa un campo de la tabla a la cual pertenece
Las relaciones uno a uno y uno a muchos se mantienen, en caso de las relaciones muchos a muchos, están nos generan otra tabla que relacionaran las dos tablas en vinculo, con los campos que se necesiten para esta relación Las relaciones nos generan llaves foráneas, se definen así: la tabla del lado de muchos hereda la llave primaria de la tabla del lado de uno Aplicando las anteriores consideraciones nuestro modelo físico quedaría de la siguiente forma.
Las líneas punteadas y continuas definen la posibilidad de la relación, es decir, si es obligatoria o no. Ejemplo, Un socio puede hacer una o varias reservas, en este caso un socio puede estar registrado y no necesariamente tiene que hacer reservas, en estos casos de No Obligatoriedad se define en nuestro modelo con una línea punteada. En
caso contrario cuando es obligatorio, se define con una línea continua, ejemplo Una cuota debe ser pagada por un socio, el socio está registrado y cuando se registra la cuota debe necesariamente relacionarse el socio que la paga. 1.3
Modelo Físico
Del modelo lógico pasamos al modelo físico, antes de eso hay que verificar que nuestro modelo resultante este normalizado, es decir este en 3 forma normal, para evitar complicaciones y posibles errores de estructura en un futuro. Una vez verificado eso, podemos pasar al modelo físico, este modelo es el final, de este modelo podemos pasar ahora si a realizar nuestra base de datos dentro de un motor gestor de base de datos. En este modelo vamos a definir el tipo de dato para cada campo, es decir, si es numérico, si son cadenas de caracteres, o fechas, etc. Antes de eso es importante saber en qué motor de bases de datos se va a montar nuestra base de datos, en nuestro caso es Oracle. Una vez con esto claro, hay que revisar los tipos de datos que Oracle nos permite ingresar. La siguiente tabla es una referencia de los tipos de datos en Oracle TIPO
CARACTERISTICAS OBSERVACIONES
CHAR
Cadena de caracteres (alfanuméricos) de longitud fija
Entre 1 y 2000 bytes como máximo. Aunque se introduzca un valor más corto que el indicado en el tamaño, se rellenará al tamaño indicado. Es de longitud fija, siempre ocupará lo mismo, independientemente del valor que contenga
VARCHAR2
Cadena de caracteres de longitud variable
Entre 1 y 4000 bytes como máximo. El tamaño del campo dependerá del valor que contenga, es de longitud variable.
VARCHAR
Cadena de caracteres de longitud variable
En desuso, se utiliza VARCHAR2 en su lugar
NCHAR
Cadena de caracteres de longitud fija que sólo almacena caracteres Unicode
Entre 1 y 2000 bytes como máximo. El juego de caracteres del tipo de datos (datatype) NCHAR sólo puede ser AL16UTF16 ó UTF8. El juego de caracteres se especifica cuando se crea la base de datos Oracle
NVARCHAR2
Cadena de caracteres de
Entre 1 y 4000 bytes como máximo. El juego de caracteres del tipo de datos (datatype)
longitud variable que NCHAR sólo puede ser AL16UTF16 ó UTF8. sólo almacena El juego de caracteres se especifica cuando caracteres Unicode se crea la base de datos Oracle
LONG
Cadena de caracteres de longitud variable
Como máximo admite hasta 2 GB (2000 MB). Los datos LONG deberán ser convertidos apropiadamente al moverse entre diversos sistemas. Este tipo de datos está obsoleto (en desuso), en su lugar se utilizan los datos de tipo LOB (CLOB, NCLOB). Oracle recomienda que se convierta el tipo de datos LONG a alguno LOB si aún se está utilizando. No se puede utilizar en cláusulas WHERE, GROUP BY, ORDER BY, CONNECT BY ni DISTINCT Una tabla sólo puede contener una columna de tipo LONG. Sólo soporta acceso secuencial.
LONG RAW
Almacenan cadenas binarias de ancho variable
Hasta 2 GB. En desuso, se sustituye por los tipos LOB.
RAW
Almacenan cadenas binarias de ancho variable
Hasta 32767 bytes. En desuso, se sustituye por los tipos LOB.
LOB (BLOG, CLOB, NCLOB, BFILE)
Permiten almacenar y manipular bloques grandes de datos no estructurados (tales como texto, imágenes, videos, sonidos, etc.) en formato binario o del carácter
Admiten hasta 8 terabytes (8000 GB). Una tabla puede contener varias columnas de tipo LOB. Soportan acceso aleatorio. Las tablas con columnas de tipo LOB no pueden ser replicadas.
BLOB
Permite almacenar datos binarios no estructurados
Admiten hasta 8 terabytes
CLOB
Almacena datos de tipo carácter
Admiten hasta 8 terabytes
NCLOB
Almacena datos de
Admiten hasta 8 terabytes.
tipo carácter
BFILE
ROWID
Almacena datos binarios no estructurados en archivos del sistema operativo, fuera de la base de datos. Una columna BFILE almacena un localizador del archivo a uno externo que contiene los datos
Almacenar la dirección única de cada fila de la tabla de la base de datos
Guarda los datos según el juego de caracteres Unicode nacional.
Admiten hasta 8 terabytes. El administrador de la base de datos debe asegurarse de que exista el archivo en disco y de que los procesos de Oracle tengan permisos de lectura para el archivo.
ROWID físico almacena la dirección de fila en las tablas, las tablas en clúster, los índices, excepto en las índices-organizados (IOT). ROWID lógico almacena la dirección de fila en tablas de índice-organizado (IOT). Un ejemplo del valor de un campo ROWID podría ser: "AAAIugAAJAAC4AhAAI". El formato es el siguiente: Para "OOOOOOFFFBBBBBBRRR", donde: OOOOOO: segmento de la base de datos (AAAIug en el ejemplo). Todos los objetos que estén en el mismo esquema y en el mismo segmento tendrán el mismo valor. FFF: el número de fichero del tablespace relativo que contiene la fila (fichero AAJ en el ejemplo). BBBBBB: el bloque de datos que contiene a la fila (bloque AAC4Ah en el ejemplo). El número de bloque es relativo a su fichero de datos, no al tablespace. Por lo tanto, dos filas con números de bloque iguales podrían residir en diferentes datafiles del mismo tablespace. RRR: el número de fila en el bloque (fila AAI en el ejemplo). Este tipo de campo no aparece en los
SELECT ni se puede modificar en los UPDATE, ni en los INSERT. Tampoco se puede utilizar en los CREATE. Es un tipo de datos utilizado exclusivamente por Oracle. Sólo se puede ver su valor utilizando la palabra reservada ROWID, por ejemplo:
selectrowid, nombre, apellidos from clientes Ejemplo 2:
SELECT ROWID, SUBSTR(ROWID,15,4) "Fichero", SUBSTR(ROWID,1,8) "Bloque", SUBSTR(ROWID,10,4) "Fila" FROM proveedores
Ejemplo 3: una forma de saber en cuántos ficheros de datos está alojada una tabla: SELECT COUNT(DISTINCT(SUBSTR(ROWID,7,3))) "Numero ficheros " FROM facturación UROWID
NUMBER
ROWID universal
Admite ROWID a tablas que no sean de Oracle, tablas externas. Admite tanto ROWID lógicos como físicos.
Almacena números fijos y en punto flotante
Se admiten hasta 38 dígitos de precisión y son portables a cualquier entre los diversos sistemas en que funcione Oracle. Para declarar un tipo de datos NUMBER en un CREATE ó UPDATE es suficiente con: nombre_columna NUMBER opcionalmente se le puede indicar la precisión (número total de dígitos) y la escala (número de dígitos a la derecha de la coma, decimales, los cogerá de la precisión indicada): nombre_columna NUMBER (precisión, escala) Si no se indica la precisión se tomará en función del número a guardar, si no se indica la escala se tomará escala cero. Para no indicar la precisión y sí la escala podemos utilizar: nombre_columna NUMBER (*, escala) Para introducir números que no estén en el formato estándar de Oracle se puede
utilizar la función TO_NUMBER. FLOAT
DATE
Almacena tipos de datos numéricos en punto flotante
Es un tipo NUMBER que sólo almacena números en punto flotante
El tipo de datos DATE almacena el año (incluyendo el siglo), el mes, el día, las horas, los minutos y los segundos (después de medianoche). Oracle utiliza su propio formato interno para almacenar fechas. Los tipos de datos DATE se almacenan en campos de longitud fija de siete octetos cada uno, correspondiendo al siglo, año, mes, día, hora, minuto, y al segundo. Para entrada/salida de fechas, Oracle Almacena un punto utiliza por defecto el formato DD-MMMen el tiempo (fecha y AA. Para cambiar este formato de fecha por hora) defecto se utiliza el parámetro NLS_DATE_FORMAT. Para insertar fechas que no estén en el mismo formato de fecha estándar de Oracle, se puede utilizar la función TO_DATE con una máscara del formato: TO_DATE (el “13 de noviembre de 1992”, “DD del MES, YYYY”)
Almacena datos de tipo hora, TIMESTAMP fraccionando los segundos Almacena datos de tipo hora incluyendo TIMESTAMP la zona horaria WITH TIME (explícita), ZONE fraccionando los segundos TIMESTAMP Almacena datos de WITH tipo hora incluyendo
Cuando se usa un SELECT para mostrar los datos de este tipo, el valor de la hora será
LOCAL la zona horaria local TIME ZONE (relativa), fraccionando los segundos XMLType
Tipo de datos abstracto. En realidad se trata de un CLOB.
ajustado a la zona horaria de la sesión actual
Se asocia a un esquema XML para la definición de su estructura.
Nuestro modelo físico resultaría así:
2. Creación de Usuario para el esquema Nuestro ejercicio está preparado para montarlo. Para montarlo lo primero que debemos hacer es crear un usuario que va a cumplir el rol de administrador de nuestra base de datos, el DBA. Entramos a la línea de comandos SQL de Oracle.
Nos conectamos como system Conn system/contraseña
En donde contraseña es el password que hubieran definido para el usuario sys y system al instalar Oracle. 2.1 Creación de Usuario Creamos el usuario DBA de nuestro ejercicio, la sintaxis es CREATE USER usuario IDENTIFIED BY contraseña DEFAULT TABLESPACE tablespace TEMPORARY TABLESPACE tablespace_temporal; Como vemos en el anterior comando se puede definir el tablespace que va a utilizar el nuevo usuario, los tablespace son unidades lógicas de almacenamiento que maneja Oracle y es en donde se almacenan los objetos como tablas, índices, vistas, etc. Los tablespace que son temporales solo pueden guardar objetos que son temporales, es decir que las tablas, índices, vistas y ese tipo de objetos que son permanentes no los guarda en los tablespace temporales. Si no definimos el tablespace Oracle define al nuevo usuario por defecto SYSTEM, y como tablespace temporal TEMP. Por tal razón antes de crear el nuevo usuario vamos a crear un tablespace para asignárselo al usuario y que allí queden guardados todos los objetos. Par esto ejecutamos la siguiente sintaxis CREATE TABLESPACE tablespace DATAFILE „c:\ORACLEXE\ORADATA\XE\datafile.dbf‟‟ SIZE 100M;
Creado el tablespace ahora si proseguimos a crear el nuevo usuario lo llamaremos „DBAdeportivos‟ identificado por la contraseña „deportivos‟.
2.2 Asignación de Privilegios Después de crear el usuario debemos darle privilegios para que se pueda conectar y pueda crear objetos, utilizamos la siguiente sentencia: GRANT CONNECT TO usuario; Para dar privilegio de conectarse GRANT RESOURCE TO usuario; Para conceder privilegios de crear objetos
3. Creación de Tablas Nos conectamos a Oracle con el usuario creado.
E iniciamos a crear las tablas según nuestro último modelo.
3.1
Creaci贸n de la Tabla Socio
Create table SOCIO ( No_Identificacion varchar2(20) not null primary key, Nombre Varchar2(50) not null, Direccion varchar2(35) not null, Telefono varchar2(15) not null, Ciudad varchar2(20) not null, Provincia varchar2(20) null, Estado varchar2(1) not null );
3.2
Creaci贸n de la tabla Cuota
Create table CUOTA ( Numero number not null primary key, Cod_Socio varchar2(20) not null, Estado varchar2(1) not null, Monto number not null, Fecha_Pago date not null );
3.3
Creaci贸n de la tabla Reserva
Create table RESERVA ( Codigo number not null primary key, Cod_Socio varchar2(20) not null, Fecha date not null );
3.4
Creaci贸n de la tabla Instalaci贸n
Create table INSTALACION ( Codigo number not null primary key, Descripcion varchar2(50) not null, Estado varchar2(1) );
3.5
Creaci贸n de la tabla Articulo
Create table ARTICULO ( Codigo number not null primary key, Descripcion varchar2(50) not null, Marca varchar2(30) not null, Estado varchar2(1) not null );
3.6
Creaci贸n de la tabla Reserva_Instalacion
Create table RESERVA_INSTALACION ( Codigo number not null primary key, Cod_Reserva number not null, Cod_Instalacion number not null, Hora_Inicio varchar2(10) not null, Hora_Fin varchar2(10) not null, Total_Horas number not null );
3.7
Creaci贸n de la tabla Reserva_Inst_Articulo
Create table RESERVA_INST_ARTICULO ( Codigo number not null primary key, Cod_Reserva_Instalacion number not null, Cod_Articulo number not null, Cantidad number not null );
4. Creaci贸n de Llaves
En cada una de la creaci贸n de las tablas le definimos a los campos que eran llave primaria por medio de primary key. Pero aun nos falta decirle a Oracle cuales son nuestras llaves for谩neas para definir las relaciones entre las tablas creadas. Para esto alteramos las tablas y agregamos constraint. ALTER TABLE tabla ADD CONSTRAINT nombreconstraint FOREIGN KEY (campo) REFERENCES tablaReferencia(campoReferencia) 4.1
Tabla Cuota
Alter table CUOTA add Constraint fk_CuoSoc_SocIde Foreign key (Cod_Socio) References SOCIO(No_Identificacion);
4.2
Tabla Reserva
Alter Table RESERVA add Constraint fk_ResSoc_SocIde Foreign key (Cod_Socio) References SOCIO(No_Identificacion);
4.3
Tabla Reserva_Instalacion
Alter Table RESERVA_INSTALACION add ( Constraint fk_RinsRes_ResCod Foreign key (Cod_Reserva) References RESERVA (Codigo) , Constraint fk_RinsIns_InsCod Foreign Key (Cod_Instalacion) References INSTALACION(Codigo) );
4.4
Tabla Reserva_Ins_Articulo
Alter Table RESERVA_INST_ARTICULO add ( Constraint fk_RartRins_ArtCod Foreign key (Cod_Reserva_Instalacion) References RESERVA_INSTALACION(Codigo) , Constraint fk_RartArt_ArtCod Foreign Key (Cod_Articulo) References ARTICULO(Codigo) );