Database Foundations (Oracle)

MATERIAL TÉCNICO
DE APOYO
 Database Foundations (Oracle)

TAREA N°01

Creación y Modelamiento de Base de Datos

Formas Normales – Normalización de Base de Datos

Figura N° 01: Formas Normales

Normalización.

La normalización de bases de datos consiste en aplicar una serie de reglas a las

relaciones obtenidas tras el paso del modelo entidad-relación hacia el modelo
relacional.

La normalización se usa en las bases de datos relacionales para:

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

En el modelo relacional, las relaciones se conocen generalmente como tablas,

aunque para que una tabla sea considerada como una relación debe cumplir con las
siguientes restricciones:
• Cada columna debe tener su nombre único.
• No puede haber dos filas iguales. No se permiten los duplicados.
• Todos los datos en una columna deben ser del mismo tipo.

La normalización se aplica a las tablas de una base de datos. Al referirse como que
una base de datos está en la forma normal N significa que todas sus tablas están en
la forma normal N.

2
 Database Foundations (Oracle)

Generalmente, las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayoría de las bases de datos. El creador de las 3 primeras
formas normales fue Edgar F. Codd.

Edgar F. Codd.
Edgar Frank «Ted» Codd fue un científico de la computación. Inglés que, mientras
trabajaba para IBM, inventó el modelo relacional de gestión de base de datos, la
base teórica de las bases de datos relacionales. Hizo otras valiosas contribuciones
a la informática, pero el modelo relacional, una teoría general muy influyente de la
gestión de datos, sigue siendo su logro más mencionado.

Formas Normales.

Primera Forma Normal (1FN).

• Una tabla está en Primera Forma Normal si:
• Todos los atributos son atómicos. Un atributo es atómico si los elementos del
dominio son indivisibles, mínimos.
• La tabla contiene una clave primaria única.
• La clave primaria no contiene atributos nulos.
• No debe existir variación en el número de columnas.
• Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
• Debe Existir una independencia del orden tanto de las filas como de las columnas,
es decir, si los datos cambian de orden no deben cambiar sus significados.
• Una tabla no puede tener múltiples valores en cada columna.
• Los datos son atómicos (a cada valor de X le pertenece un valor de Y y viceversa).

Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN).

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos
que no forman parte de ninguna clave dependen de forma completa de la clave
principal. Es decir que no existen dependencias parciales. (Todos los atributos que
no son clave principal deben depender únicamente de la clave principal).

En otras palabras, podríamos decir que la segunda forma normal está basada en el
concepto de dependencia completamente funcional. Una dependencia funcional es
completamente funcional si al eliminar los atributos A de X significa que la
dependencia no es mantenida, esto es que, una dependencia funcional es una
dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la
dependencia todavía se mantiene, esto es

Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado

y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un
empleado en dicho proyecto) es completamente funcional dado que ni DNI
HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la

3
 Database Foundations (Oracle)

dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es

parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la
dependencia.

Tercera Forma Normal (3FN).

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional
transitiva entre los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un

esquema de relación R es una dependencia transitiva si hay un conjunto de atributos
Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en

EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el
atributo clave SSN es transitiva vía DNUMBER porque las dependencias
SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es
un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la
dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado
que DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relación está en 3 Forma Normal Elmasri-Navathe,2

si para toda dependencia funcional, se cumple al menos una de las siguientes
condiciones:
• Es superllave o clave.
• Es atributo primo de; esto es, si es miembro de alguna clave en.

Además, el esquema debe cumplir necesariamente, con las condiciones de segunda

forma normal.

Forma Normal de Boyce-Cood (FNBC).

La tabla se encuentra en FNBC si cada determinante, atributo que determina
completamente a otro, es clave candidata. Deberá registrarse de forma anillada ante
la presencia de un intervalo seguido de una formalización perpetua, es decir las
variantes creadas, en una tabla no se llegarán a mostrar, si las ya planificadas, dejan
de existir.

Formalmente, un esquema de relación está en FNBC, si y sólo si, para toda

dependencia funcional válida en, se cumple que: es superllave o clave.

De esta forma, todo esquema que cumple FNBC, está además en 3FN; sin embargo,
no todo esquema que cumple con 3FN, está en FNBC.

Cuarta Forma Normal (4FN).

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias
múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave
candidata o un conjunto de claves primarias.

4
 Database Foundations (Oracle)

Quinta Forma Normal (5FN).

• Una tabla se encuentra en 5FN si:
• La tabla está en 4FN.
• No existen relaciones de dependencias no triviales que no siguen los criterios de
las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si,
y sólo si, cada relación de dependencia se encuentra definida por las claves
candidatas.

Nota: La normalización es una técnica utilizada para diseñar

tablas en las que las redundancias de datos se reducen al
mínimo. Las primeras tres formas normales (1FN, 2FN y 3FN)
son las más utilizadas. Desde un punto de vista estructural,
las formas de mayor nivel son mejores que las de menor nivel,
porque aquellas producen relativamente pocas redundancias
de datos en la base de datos. En otras palabras, 3FN es mejor
que 2FN y ésta, a su vez, es mejor que 1FN. Casi todos los
diseños de negocios utilizan la 3FN como forma ideal.

¿Qué es la gestión de requisitos?

La gestión de requisitos es una opción para garantizar que los entregables finales
del proyecto cumplan tanto con las necesidades de los clientes como con las de los
participantes internos. En este caso, un requisito es algo que las partes interesadas
necesitan o desean de tu producto. Esas partes interesadas pueden ser
colaboradores internos (como personas que trabajan en otros departamentos) o
participantes externos (como los clientes).

Por lo general, quienes aplican la gestión de requisitos son los equipos de desarrollo
que trabajan con productos y funciones de software, pero también se usa en general
para la gestión de proyectos. Por ejemplo, un requisito podría ser una función que
permitiera que los clientes usaran con éxito el producto o algún aspecto de tu
producto que ayudara a que los colaboradores de otros departamentos cumplieran
sus objetivos de negocios.

Antes de empezar a trabajar en un producto, deberás acordar los requisitos exactos

para brindarles a las partes interesadas lo que realmente necesitan. La gestión de
requisitos te permite documentar y establecer las prioridades entre los requisitos, dar
seguimiento a los cambios y mantenerte alineado con los demás participantes a lo
largo del ciclo de vida del proyecto. Además, te servirá para gestionar los cambios
de requisitos y para mantener al proyecto dentro del alcance propuesto.

¿Qué es un requisito?
Un requisito es un componente que necesitas implementar para finalizar una función
o producto. En otras palabras, es algo que tu producto debe tener o hacer para
cumplir con las expectativas de las partes interesadas. Los productos de software
pueden tener cientos de requisitos. Pero, independientemente de cuántos requisitos
tenga un producto, todos deben ser:

5
 Database Foundations (Oracle)

• Necesarios: necesitas cumplir con este requisito para alcanzar los objetivos del
producto o de negocios.
• Específicos: el requisito debe estar bien detallado y tener un propósito claro.
• Fáciles de entender: el requisito debe estar redactado con claridad y ser fácil de
entender.
• Precisos: el requisito debe contener información precisa suficiente sobre el
inconveniente que resuelve o la necesidad que cubre. Es decir, en vez de
solamente describir lo que hace falta hacer; además, deberías aclarar por qué es
importante satisfacer ese requisito.
• Viables: deberías averiguar si el requisito se puede implementar con la
infraestructura de código y tecnología que tienes actualmente.
• Comprobables: deberías poder probar el requisito mediante pruebas de
usuarios, pruebas A/B u otro método.

¿Por qué es importante la gestión de requisitos?

La gestión de requisitos es indispensable para crear un producto de primer nivel. A

continuación, te contamos los motivos:

Entrega las funciones correctas. El proceso de gestión de requisitos es útil para

definir lo que el usuario necesita mediante la interpretación de su interacción con el
producto. Resulta muy útil para, primero y ante todo, alinear los entregables con las
necesidades esenciales de tus clientes.

Se alinea con los objetivos de negocios. Cuando documentes y establezcas las

prioridades de los requisitos, asegúrate de que queden alineados con los objetivos
generales. Por ejemplo, un requisito de traducir la aplicación a 12 idiomas serviría
para respaldar el objetivo de negocios de expandirse a mercados internacionales. Si
algún requisito no concuerda con los objetivos de negocios, probablemente
signifique que debas invertir los recursos en alguna otra parte o tener una muy buena
razón que justifique por qué el requisito es realmente importante.

Evita la corrupción del alcance. Los requisitos funcionan como el alcance de un

proyecto, con ellos se definen los límites y se determina exactamente con qué
objetivos y entregables se trabajará. La definición anticipada de los requisitos te
ayuda a identificar potenciales obstáculos y a poner un límite cuando alguien intenta
agregar requisitos extra.

Sortea los obstáculos. Crear un producto no es nada fácil; por lo menos, hay una
etapa de desarrollo del software, otra de diseño y otra de pruebas; sin mencionar las
secuencias de código complejo y sistemas de ingeniería con los que hay que
trabajar. La gestión de requisitos te ayuda a planificar el desarrollo de un producto
dentro de las limitaciones de ese código y a dar seguimiento a lo que debes lograr a
cada paso del proceso de desarrollo del producto.

6
 Database Foundations (Oracle)

¿Quién es responsable de la gestión de requisitos?

La persona responsable de la gestión de requisitos dependerá de tu proyecto o
equipo en particular. Pero, en general, los encargados o gerentes de producto son
quienes gestionan los requisitos de los equipos de desarrollo. Estos dos roles son
muy similares, excepto que los encargados de producto son un rol estándar en los
equipos Scrum mientras que el rol de los gerentes de producto es más universal,
independientemente de si el equipo aplica una metodología ágil o no. Si, en cambio,
trabajas con un proyecto más general, el gerente de proyecto será el responsable de
la gestión de los requisitos.
En la gestión de requisitos, se requiere una colaboración interdisciplinaria entre tu
equipo y los demás participantes del proyecto. Debes reunir los comentarios de todas
las partes interesadas, trabajar juntos para entender cada requisito y ayudar al
equipo a planificar cómo se ocuparán de cada necesidad planteada. Esto significa
que la persona que gestiona los requisitos de tu proyecto debe tener habilidades
sólidas para la colaboración y sobresalir en la comunicación interdisciplinaria porque
será el centro de todo.

Requisitos del sistema

Con los requisitos del sistema se define qué hará el producto. Piénsalo de este modo,
mientras que con los requisitos del usuario se explican el “por qué” y el “qué” de las
funciones del producto desde la perspectiva del usuario, con los requisitos del
sistema se define “cómo” se construye la función, ahora desde la perspectiva del
equipo de ingeniería.
En la mayoría de los casos, los requisitos del sistema se desglosan en requisitos
funcionales y no funcionales. Con los requisitos funcionales se define qué hará el
producto, mientras que con los no funcionales se determina en qué medida las
funciones del producto trabajarán como se espera. Esto significa que, normalmente,
los requisitos no funcionales están vinculados a la seguridad, el rendimiento y la
fiabilidad.

Requisitos funcionales:

Que en cada listado de productos se almacene la siguiente información: el tipo de

producto, la fecha de creación, el autor, la URL y el estado de la publicación.
Que no se puedan crear productos nuevos a menos que los autores seleccionen un
tipo de producto en el menú desplegable.
Que la barra de búsqueda incluya una opción para aplicar los siguientes filtros extra:
el tipo de producto, la fecha de creación, el autor, la URL y el estado de la publicación.
Que se puedan seleccionar varios filtros a la vez.

Requisitos no funcionales
Que los resultados de las búsquedas aparezcan en menos de cinco segundos.
Que los resultados de las búsquedas sean 100 % precisos.

7
 Database Foundations (Oracle)

Procedimiento para desarrollar los requisitos de un sistema software que

satisfaga las necesidades de negocio.
El objetivo principal de esta actividad es desarrollar una propuesta de sistema
software como solución a las necesidades de negocio de clientes y usuarios,
haciéndolo con la mayor calidad posible e intentando asegurar que coincide con las
expectativas de clientes y usuarios.
Los ingenieros de requisitos deben elaborar la propuesta en forma de requisitos del
sistema software a desarrollar (product requirements en terminología CMMI-DEV),
usando como entrada la información que se va generando en el procedimiento
Identificar las necesidades de negocio de clientes y usuarios. Lo habitual es
comenzar por los aspectos más generales del sistema (su visión general), para ir
avanzando en el nivel de detalle hasta que se considere suficiente como para que
pueda continuarse el desarrollo sin tener que plantear preguntas continuas sobre la
conducta del sistema a desarrollar.
Durante esta actividad es frecuente que en cualquier momento se identifiquen y
registren diversos tipos de problemas en los requisitos, cuya solución debe
gestionarse por la actividad de Gestionar los problemas en los requisitos dentro del
procedimiento Gestionar los requisitos del sistema software a desarrollar.

Figura N° 02: Formas Normales

8
 Database Foundations (Oracle)

Detalle de las actividades:

Título Desarrollar la visión general del sistema

Descripción Su objetivo principal es comenzar a definir el sistema software (la
solución) que satisfaga las necesidades de negocio de clientes y
usuarios (el problema). Para ello, se definen los requisitos
generales y se comienzan a especificar los casos de uso del
sistema en su versión inicial. Conforme avance el proceso de
ingeniería de requisitos, los requisitos generales se irán
detallando en requisitos más específicos y los casos de uso que
se considere oportuno irán evolucionando hacia su forma
detallada.
Riesgos de no efectuar la actividad:
• Esta tarea es esencial para el desarrollo de un sistema
software, por lo que no se contempla la posibilidad de no
realizarla.
Tareas Tareas:
• Realizar un estudio de la situación inicial
• Obtener los requisitos generales del subsistema
• Definir los casos de uso del sistema

Técnicas:
Las principales técnicas que se suelen emplear para la realización
de esta tarea son:
• Especificación de requisitos (usando la plantilla para
requisitos generales propuesta en MADEJA).
• Especificación de casos de uso (usando la plantilla
simplificada para casos de uso propuesta en MADEJA).
Responsable Tarea1, director del Proyecto
Tarea2, director del Proyecto
Tarea3, director del Proyecto
Productos Entrada:
• Pliego de Prescripciones Técnicas del proyecto, si existe.
Puede contener información relevante sobre la visión general
del sistema.
• Oferta Seleccionada del proyecto, si existe. Puede contener
información relevante sobre la visión general del sistema.
• Estudio de Viabilidad del Sistema, si existe. Debe contener
información relevante sobre la visión general del sistema.
• Objetivos de negocio, que deben guiar el desarrollo de la visión
general del sistema.
• Modelo de negocio a implantar, que, junto con los objetivos de
negocio, debe guiar el desarrollo de la visión general del
sistema.

9
 Database Foundations (Oracle)

Salida:
• Requisitos generales del sistema, principal producto resultante
de esta tarea junto con la versión inicial de los casos de uso.
Deben especificar las características principales del sistema a
desarrollar.
• Casos de uso del sistema (versión inicial), principal producto
resultante de esta tarea junto con los requisitos generales.
Deben comenzar a especificar cómo utilizarán los usuarios el
futuro sistema a desarrollar para realizar sus tareas dentro de
los procesos de negocio de la organización.

El Modelo base de datos: Definición y tipos

Cuando hablamos de crear una base de datos, no podemos olvidarnos del modelo
de base datos; este concepto determina en muchos casos el tipo de base de datos
que vamos a emplear. En esta entrada vamos a explicar en qué consisten los
modelos de bases de datos y qué tipos hay.

¿Qué es un modelo de base de datos?

Tipos de modelos de bases de datos

• Modelo de base de datos relacional

• Modelo jerárquico
• Modelo de red
• Modelo orientado a objetos
• Modelo relacional de objetos
• Modelo entidad-relación
• Modelo de archivo invertido
• Modelo plano
• Modelo multidimensional
• Modelo semiestructurado
• Modelo de contexto
• Modelo asociativo
• Modelos de bases de datos NoSQL

¿Qué es un modelo de base de datos?

Un modelo de base de datos es la estructura lógica que adopta la base de base

datos, incluyendo las relaciones y limitaciones que determinan cómo se
almacenan y organizan y cómo se accede a los datos. Así mismo, un modelo de
base de datos también define qué tipo de operaciones se pueden realizar con los
datos, es decir, que también determina cómo se manipulan los mismos,
proporcionando también la base sobre la que se diseña el lenguaje de consultas.

10
 Database Foundations (Oracle)

En general, prácticamente todos los modelos de base de datos pueden

representarse a través de un diagrama de base de datos (en esta entrada veremos
algunos).

Tipos de modelos de bases de datos.

Tal y como ocurre con las bases de datos, existen diferentes tipos de modelos de
bases de datos, como vamos a ver en los próximos puntos. Qué modelo elegir para
nuestra base de datos dependerá, por un lado, del sistema de gestión de bases de
datos que estemos usando, puesto que este debe se compatible con el modelo de
datos (lo habitual es que los SGBD estén desarrollados para emplear un modelo de
base de datos en concreto, aunque hay algunos compatibles con múltiples modelos).

Modelo de base de datos relacional.

El modelo de base de datos relacional es uno de los más comunes. Este modelo es
el que emplean las bases de datos relacionales y ordena los datos en tablas
(relaciones) compuestas por columnas y filas.
Cada columna alberga un atributo de la entidad (nombre, dirección, fecha de
nacimiento…); a los atributos de una relación se los llama dominio. Escogiendo un
atributo en concreto o una combinación de varios tenemos una clave primaria, a la
que se puede hacer referencia en otras tablas, en las que será una clave externa.

En cada fila (tupla) se incluyen datos sobre una instancia específica de la entidad
(por ejemplo, un cliente específico).

Además, el modelo también representa el tipo de relaciones entre las tablas, que
pueden ser uno a uno, uno a muchos o muchos a muchos.
Podéis ver la estructura del modelo relacional de base de datos en el ejemplo:

Figura N° 03: Esquema modelo base de datos relacional

11
 Database Foundations (Oracle)

Modelo jerárquico
Si vamos a emplear una base datos jerárquica, el modelo de datos que emplearemos
será el jerárquico, que se caracteriza por presentar los datos en una estructura de
árbol invertido, donde cada registro tiene un único nodo raíz, del que surgen otros
nodos (registros); los nodos en un mismo nivel son nodos padre, cada nodo padre
tiene el mismo nodo raíz, y puede tener nodos hijos, pero los nodos hijos solo pueden
tener un nodo padre. Este modelo se emplea poco actualmente.

En este modelo, los registros de un mismo nivel se clasifican en un orden específico.

Su estructura se vería como en el siguiente ejemplo:

Figura N° 04: Esquema modelo base de datos jerárquico

Modelo de red
El modelo en red de base de datos parte del modelo jerárquico, pero aquí se permiten
las relaciones de uno a muchos o de muchos a muchos entre registros vinculados,
teniendo registros principales múltiples. El modelo se crea a través de conjuntos de
registros relacionados; cada uno de estos conjuntos consiste en un registro
propietario o principal y uno o más registros miembros o secundarios. Además, un
registro puede ser miembro o secundario en diferentes conjuntos. Es decir, que en
este modelo se permite que los nodos hijos tengan más de uno nodo padre, de
manera que se pueden representar relaciones más complejas.

Aquí puedes ver un ejemplo de este modelo de base de datos de red.

12
 Database Foundations (Oracle)

Figura N° 05: Esquema modelo base de datos en red

Modelo orientado a objetos.

El modelo de la base de datos orientada a objetos define la base de datos como una
colección de objetos utilizados en la programación orientada a objetos (es decir, que
emplear lenguajes como C++ o Java, por ejemplo). Este modelo de base de datos
utiliza tablas también, pero no solo se limita a ellas y permite almacenar información
muy detallada sobre cada objeto.

Los objetos se dotan de un conjunto de características propias, que a su vez les

diferencian de objetos similares. Los objetos similares pueden agruparse en una
clase y cada objeto de esta es una instancia. Las clases intercambian datos entre sí
a través métodos (mensajes).

13
 Database Foundations (Oracle)

Figura N° 06: Esquema modelo base de datos orientado a objetos

Modelo relacional de objetos.

El modelo relacional de objetos combina en un modelo híbrido el modelo de base de
datos relacional y el orientado a objetos, de manera que funciona de manera similar
al relacional, pero incorpora funciones del modelo orientado a objetos, como los
propios objetos, las clases, la herencia y el poliformismo. Además, permite una mejor
escalabilidad y se pueden almacenar un gran volumen de datos dentro de las clases.

Modelo entidad-relación
El modelo entidad-relación es básicamente el paso previo a uno modelo de bases
datos relacional, puesto que se trata de un diagrama elaborado a través de unos
elementos básicos y su relación entre ellos:

• Entidades (son los objetos que se representan en la base de datos).

• Atributos (son el contenido de la entidad, sus características). A los atributos se
les asigna un clave para distinguirlos de los demás registros.
• Relación (el vínculo que define la dependencia entre varias entidades).
• Cardinalidad (es la participación entre entidades, que pueden ser uno a uno, uno
a varios o varios a varios).

En el diagrama las entidades se representan con un rectángulo, las relaciones con

un rombo y los atributos con un óvalo. Lo vemos en un ejemplo:

14
 Database Foundations (Oracle)

Figura N° 07: Esquema modelo base de datos entidad relación

Modelo plano.

El modelo de bases de datos plano, los datos se estructuran en dos dimensiones (de
ahí lo de estructura plana), en la que todos los objetos en una columna concreta
tienen valores del mismo tipo y todos los objetos de la misma fila están relacionados
entre ellos.

Por ejemplo, en una base de datos que recoja solo el nombre de usuario y la
contraseña, cada fila recogerá el nombre y la contraseña correspondiente para cada
usuario.

Este modelo tabular de base de datos es el precursor del modelo relacional.

Figura N° 08: Esquema modelo base de datos plano

Modelos de bases de datos NoSQL

Ya hemos visto un modelo de bases de datos NoSQL, también llamadas bases de
datos no relacionales, el modelo de base de datos orientado a objetos, pero existen
otros:
• Modelo de base de datos gráfico, similar al de red, pero más flexible, puesto que
permite que cualquier nodo se pueda conectar a cualquier otro.
• Modelo multivalor, que nace del modelo relacional, pero en el que los atributos
pueden contener una lista de datos en vez de un solo punto de datos.
• Modelo de documentos, empleado para almacenar y administrar documentos o
datos semiestructurados, en vez de datos atómicos (como hacen las bases
relacionales).

15
 Database Foundations (Oracle)

¿Cómo realizar un modelado de datos?

• El primer paso antes de diseñar una base de datos es modelar los datos que
vamos a almacenar en ella. El modelado de datos puede adoptar diferentes
enfoques (conceptual, empresarial, lógico o físico) y consiste en la realización de
una serie de tareas previas:
• Identificar tipos de entidades
• Identificar atributos
• Aplicar convenciones de nomenclatura
• Identificar relaciones
• Aplicar modelos de modelos de datos
• Asignar claves
• Normalizar para reducir la redundancia de datos
• Desnormalizar para mejorar el rendimiento

Claves primarias y foráneas

Las tablas se relacionan con otras tablas mediante una relación de clave primaria o
de clave foránea. Las relaciones de claves primarias y foráneas se utilizan en las
bases de datos relacionales para definir relaciones de muchos a uno entre tablas.
Las relaciones de claves primarias y foráneas entre tablas en un esquema de estrella
o copo de nieve, a veces llamadas relaciones de muchos a uno, representan las vías
de acceso a través de las cuales las tablas relacionadas se unen en la base de datos.
Estas vías de acceso de unión son la base para formar consultas de datos históricos.
Para obtener más información sobre las relaciones de muchos a uno, consulte
Relaciones de muchos a uno.

Claves primarias
Una clave primaria es una columna o un conjunto de columnas en una tabla cuyos
valores identifican de forma exclusiva una fila de la tabla. Una base de datos
relacional está diseñada para imponer la exclusividad de las claves primarias
permitiendo que haya sólo una fila con un valor de clave primaria específico en una
tabla.

Claves foráneas
Una clave foránea es una columna o un conjunto de columnas en una tabla cuyos
valores corresponden a los valores de la clave primaria de otra tabla. Para poder
añadir una fila con un valor de clave foránea específico, debe existir una fila en la
tabla relacionada con el mismo valor de clave primaria.

16
 Database Foundations (Oracle)

TAREA N°02

Creación de Modelos Físicos de Base de Datos

¿Qué es el modelado de datos?

El modelado de datos es el proceso de creación de una representación visual o

esquema que define los sistemas de recopilación y administración de información de
cualquier organización. Este esquema o modelo de datos ayuda a las diferentes
partes interesadas, como analistas de datos, científicos e ingenieros, a crear una
vista unificada de los datos de una organización. El modelo esboza los datos que
recoge la empresa, la relación entre los distintos conjuntos de datos y los métodos
que se usarán para almacenarlos y analizarlos.

¿Por qué es importante el modelado de datos?

Hoy en día, las organizaciones recogen una gran cantidad de datos procedentes de
muchas fuentes diferentes. Sin embargo, los datos en bruto no son suficientes. Es
necesario analizar los datos para obtener información procesable que pueda guiar a
la hora de tomar decisiones empresariales rentables. Un análisis de datos preciso
requiere de una recopilación, almacenamiento y procesamiento de datos eficientes.
Existen varias tecnologías de bases de datos y herramientas de procesamiento de
datos, así como diferentes conjuntos de datos que requieren diferentes herramientas
para un análisis eficaz.

El modelado de datos le da la oportunidad de entender sus datos y tomar las

decisiones tecnológicas correctas para almacenarlos y gestionarlos. Al igual que un
arquitecto diseña un esquema antes de construir una casa, las partes interesadas
del negocio diseñan un modelo de datos antes de crear soluciones de bases de datos
para su organización.

El modelado de datos aporta las siguientes ventajas:

• Reduce los errores en el desarrollo de software de bases de datos

• Facilita la rapidez y eficacia en el diseño y creación de bases de datos
• Crea coherencia en la documentación de los datos y el diseño del sistema en
toda la organización
• Facilita la comunicación entre los ingenieros de datos y los departamentos de
inteligencia empresarial

¿Cuáles son los tipos de modelos de datos?

El modelado de datos suele comenzar representando los datos conceptualmente y,
después, representándolos de nuevo en el contexto de las tecnologías elegidas. Los
analistas y las partes interesadas crean varios tipos de modelos de datos durante la
etapa de diseño de datos. A continuación se presentan tres tipos principales de
modelos de datos:

17
 Database Foundations (Oracle)

Modelo de datos conceptual

Los modelos de datos conceptuales ofrecen una visión global de los datos. Explican
lo siguiente:

• Qué datos contiene el sistema

• Atributos de los datos, así como las condiciones o restricciones de los mismos
• Con qué reglas empresariales se relacionan los datos
• Cómo se organizan mejor los datos
• Requisitos de seguridad e integridad de datos

Por lo general, los interesados y los analistas de la empresa crean el modelo

conceptual. Es una representación diagramática simple que no sigue las reglas
formales de modelado de datos. Lo importante es que ayude a las partes
interesadas, ya sean técnicas o no, a compartir una visión común y a ponerse de
acuerdo acerca del propósito, el alcance y el diseño de su proyecto de datos.

Ejemplo de modelo de datos conceptual

Por ejemplo, el modelo de datos conceptual de un concesionario de automóviles
podría mostrar las entidades de datos así:

1. Una entidad Salas de exhibiciones, que representa la información sobre los

diferentes puntos de venta que tiene el concesionario.
2. Una entidad Autos, que representa los diversos autos que el concesionario tiene
en stock.
3. Una entidad Clientes, que representa a todos los clientes que han hecho una
compra en el concesionario.
4. Una entidad Ventas, que representa la información sobre la venta real.
5. Una entidad Vendedores que representa la información de todos los vendedores
que trabajan en el concesionario.

Este modelo conceptual también incluiría requisitos empresariales, como los

siguientes:

• Cada auto tiene que pertenecer a una sala de exhibiciones específica.

• En cada venta tiene que haber al menos un vendedor y un cliente asociados.
• Cada auto tiene que contar con marca y número de producto.
• Para ello, cada cliente tiene que facilitar su número de teléfono y su dirección de
correo electrónico.

Así, los modelos conceptuales actúan como puente entre las reglas empresariales y
el sistema físico de gestión de bases de datos (SGBD) subyacente. Los modelos de
datos conceptuales también se denominan modelos de dominio.

18
 Database Foundations (Oracle)

Modelo de datos lógico

Los modelos de datos lógicos asignan las clases de datos conceptuales a

estructuras de datos técnicas. Ofrecen más detalles sobre los conceptos de datos y
las relaciones de datos complejas que se identificaron en el modelo conceptual, tales
como estos:

• Tipos de datos de distintos atributos (por ejemplo, cadena o número)

• Relaciones entre las entidades de datos
• Atributos primarios o campos clave de los datos

Los arquitectos de datos y los analistas trabajan juntos para crear el modelo lógico.
Siguen uno de los varios sistemas formales de modelado de datos para crear la
representación. A veces, algunos departamentos ágiles optan por saltarse este paso
y pasar directamente de los modelos conceptuales a los físicos. No obstante, estos
modelos son útiles para el diseño de grandes bases de datos, denominadas
almacenamientos de datos, y para el diseño de sistemas automáticos de
información.

Ejemplo de modelos de datos lógicos:

En nuestro ejemplo del concesionario de automóviles, el modelo de datos lógico
ampliaría el modelo conceptual y profundizaría en las clases de datos de esta forma:

• La entidad Salas de exhibiciones tiene campos como el nombre y la ubicación

como datos de texto y un número de teléfono como datos numéricos.
• La entidad Clientes tiene un campo de dirección de correo electrónico con el
formato [email protected] o [email protected]. El nombre del campo no
puede tener más de 100 caracteres.
• La entidad Ventas tiene como campos el nombre del cliente y el nombre del
vendedor, junto con la fecha de venta como tipo de dato de fecha y el importe
como tipo de dato decimal.

Así, los modelos lógicos sirven de puente entre el modelo de datos conceptual y la
tecnología y el lenguaje de base de datos subyacentes que los desarrolladores usan
para crear la base de datos. Sin embargo, son independientes de la tecnología y se
pueden implementar en cualquier lenguaje de base de datos. Los ingenieros de datos
y las partes interesadas suelen tomar decisiones tecnológicas después de haber
creado un modelo de datos lógico.

Modelo de datos físico

Los modelos de datos físicos asignan los modelos de datos lógicos a una tecnología
específica de SGBD y usan la terminología del software. Por ejemplo, dan detalles
sobre lo siguiente:

19
 Database Foundations (Oracle)

• Tipos de campos de datos representados en el SGBD

• Relaciones de datos representadas en el SGBD
• Detalles adicionales, como el ajuste del rendimiento

Los ingenieros de datos crean el modelo físico antes de la implementación del diseño
final. También siguen técnicas formales de modelado de datos para asegurarse de
cubrir todos los aspectos del diseño.

¿Cuáles son los tipos de técnicas de modelado de datos?

Las técnicas de modelado de datos son los diferentes métodos que se pueden
emplear para crear diferentes modelos de datos. Los enfoques han evolucionado con
el tiempo como resultado de las innovaciones en los conceptos de las bases de datos
y la gobernanza de los datos. A continuación, se indican los principales tipos de
modelado de datos:

Modelado de datos jerárquico

En el modelado de datos jerárquico, se pueden representar las relaciones entre los
distintos elementos de datos en formato de árbol. Los modelos de datos jerárquicos
representan relaciones de uno a varios, con parents o clases de datos raíz que se
asignan a varios children.

En el ejemplo del concesionario de automóviles, la clase principal Salas de

exhibiciones tendría como elementos secundarios a las entidades Autos y
Vendedores porque una sala de exhibiciones tiene varios autos y vendedores
trabajando en esta.

Modelado de datos gráfico

El modelado jerárquico de datos ha evolucionado con el tiempo hasta convertirse en
el modelado gráfico de datos. Los modelos de datos gráficos representan relaciones
de datos que tratan a las entidades por igual. Las entidades pueden vincularse entre
sí en relaciones de uno a varios o de varios a varios sin ningún concepto de parent
o child.

Por ejemplo, una sala de exhibiciones puede tener varios vendedores, y un vendedor
también puede trabajar en varias salas si sus turnos varían según la ubicación.

Modelado de datos relacional

El modelado de datos relacional es un enfoque de modelado popular que visualiza
las clases de datos como tablas. Las diferentes tablas de datos se unen o enlazan
entre sí mediante el uso de claves que representan la relación de las entidades del
mundo real. Puede usar la tecnología de bases de datos relacionales para almacenar
datos estructurados. Un modelo de datos relacional es un método útil para
representar la estructura de su base de datos relacional.

20
 Database Foundations (Oracle)

Por ejemplo, el concesionario de automóviles tendría modelos de datos relacionales

que representan la tabla Vendedores y la tabla Autos, como se muestra aquí:

ID del vendedor Nombre

1 María
2 Juan
ID del auto Marca del auto
C1 XYZ
C2 ABC

El ID del vendedor y del auto son claves principales que identifican de manera única
a las entidades individuales del mundo real. En la tabla de salas de exhibiciones,
estas claves principales actúan como claves foráneas que enlazan los segmentos de
datos.

ID de la sala de exhibiciones Nombre de la sala de exhibiciones ID del

vendedor ID del auto
S1 Sala de exhibiciones NY 1 C1

En las bases de datos relacionales, las claves primarias y foráneas trabajan juntas
para mostrar la relación de los datos. El cuadro anterior demuestra que las salas de
exhibiciones pueden tener vendedores y autos.

Modelado de datos entidad-relación

El modelado de datos entidad-relación (ER) usa diagramas formales para
representar las relaciones entre entidades en una base de datos. Los arquitectos de
datos usan varias herramientas de modelado ER para representar los datos.

Modelado de datos orientado a objetos

La programación orientada a objetos usa estructuras de datos llamadas objetos para
almacenar datos. Estos objetos de datos son abstracciones de software de entidades
del mundo real. Por ejemplo, en un modelo de datos orientado a objetos, el
concesionario de automóviles tendría objetos de datos como Clientes con atributos
como nombre, dirección y número de teléfono. Los datos de los clientes se
almacenan de forma que cada cliente del mundo real se represente como un objeto
de datos de cliente.
Los modelos de datos orientados a objetos superan muchas de las limitaciones de
los modelos de datos relacionales y son populares en las bases de datos multimedia.

Modelado de datos dimensional

La informática empresarial moderna usa la tecnología de almacenamiento de datos
para guardar grandes cantidades de estos para su análisis. Puede usar proyectos de
modelado de datos dimensionales para el almacenamiento y la recuperación de
datos a alta velocidad desde un almacén de datos. Los modelos dimensionales usan
datos duplicados o redundantes y priorizan el rendimiento sobre el uso de menos
espacio para el almacenamiento de datos.

21
 Database Foundations (Oracle)

Por ejemplo, en los modelos de datos dimensionales, el concesionario de

automóviles tiene dimensiones como Auto, Sala de exhibiciones y Tiempo. La
dimensión Auto tiene atributos como el nombre y la marca, pero la dimensión Sala
de exhibiciones tiene jerarquías como el estado, la ciudad, el nombre de la calle y el
nombre de la sala.

¿Qué es el proceso de modelado de datos?

El proceso de modelado de datos sigue una secuencia de pasos que tiene que hacer
repetidamente hasta crear un modelo de datos completo. Dentro de cualquier
organización, varias partes interesadas se reúnen para crear una visión completa de
los datos. Aunque los pasos varían según el tipo de modelado de datos, lo que sigue
es una visión general.

Paso 1: identificar las entidades y sus propiedades

Identifique todas las entidades de su modelo de datos. Cada entidad tiene que ser
lógicamente distinta de todas las demás y puede representar personas, lugares,
cosas, conceptos o eventos. Cada entidad es distinta ya que tiene una o más
propiedades únicas. Puede pensar en las entidades como sustantivos y en los
atributos como adjetivos en su modelo de datos.

Paso 2: identificar las relaciones entre entidades

Las relaciones entre las distintas entidades son el núcleo del modelado de datos.
Las reglas empresariales definen inicialmente estas relaciones en un nivel
conceptual. Puede pensar en las relaciones como los verbos de su modelo de datos.
Por ejemplo, el vendedor vende muchos autos, o la sala de exhibiciones emplea a
muchos vendedores.

Paso 3: identificar la técnica de modelado de datos

Después de entender conceptualmente sus entidades y sus relaciones, puede

determinar la técnica de modelado de datos que mejor se adapte a su caso de uso.
Por ejemplo, puede usar el modelado de datos relacional para los datos
estructurados, pero el modelado de datos dimensional para los datos no
estructurados.

Paso 4: optimizar y repetir

Puede optimizar aún más su modelo de datos para adaptarlo a sus necesidades
tecnológicas y de rendimiento.

Por lo general, estos pasos se repiten a medida que la tecnología y los requisitos
cambian con el tiempo.

22
 Database Foundations (Oracle)

Figura N° 09: Optimizar y repetir el modelo de datos

Fundamento de las bases de datos: Modelo entidad-relación

¿Qué es el modelo entidad-relación?

Como ya he comentado este modelo es solo y exclusivamente un método del que

disponemos para diseñar estos esquemas que posteriormente debemos de
implementar en un gestor de BBDD (bases de datos). Este modelo se representa a
través de diagramas y está formado por varios elementos.

Este modelo habitualmente, además de disponer de un diagrama que ayuda a

entender los datos y como se relacionan entre ellos, debe de ser completado con un
pequeño resumen con la lista de los atributos y las relaciones de cada elemento.

Elementos del modelo entidad-relación

Entidad
Las entidades representan cosas u objetos (ya sean reales o abstractos), que se
diferencian claramente entre sí.

23
 Database Foundations (Oracle)

Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller
mecánico, donde se podría crear las siguientes entidades:

Coches (objeto físico): contiene la información de cada taller.

Empleado (objeto físico): información de los trabajadores.

Cargo del empleado (cosa abstracta): información de la función del empleado.

Estas entidades se representan en un diagrama con un rectángulo

Atributos
Los atributos definen o identifican las características de entidad (es el contenido de
esta entidad). Cada entidad contiene distintos atributos, que dan información sobre
esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto,
fecha...).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad

"Coches", que nos darán información sobre los coches de nuestro supuesto taller.
Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del
propietario, marca, modelo y muchos otros que complementen la información de
cada coche

En un modelo relacional (ya implementado en una base de datos) un ejemplo de

tabla dentro de una BBDD podría ser el siguiente.

Número de chasis Matrícula DNI del propietario

5tfem5f10ax007210 4817 BFK 45338600L
6hsen2j98as001982 8810 CLM 02405068K
5rgsb7a19js001982 0019 GGL 40588860J

Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese
necesario) y seguirían la misma estructura de columnas, tras implementarlo en una
BBDD.

Relación
Es un vínculo que nos permite definir una dependencia entre varias entidades, es
decir, nos permite exigir que varias entidades compartan ciertos atributos de forma
indispensable.

Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo
(según la entidad "Cargo del empleado"). Es decir, un atributo de la entidad
"Empleados" especificará que cargo tiene en el taller, y tiene que ser idéntico al que
ya existe en la entidad "Cargo del empleado".

24
 Database Foundations (Oracle)

Las relaciones se muestran en los diagramas como rombos, que se unen a las
entidades mediante líneas.

Relaciones de cardinalidad
Podemos encontrar distintos tipos de relaciones según como participen en ellas las
entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero
un mismo cargo lo pueden compartir varios empleados.

Esto complementa a las representaciones de las relaciones, mediante un intervalo

en cada extremo de la relación que especifica cuantos objetos o cosas (de cada
entidad) pueden intervenir en esa relación.

Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo,
si tuviésemos una entidad con distintos chasis y otra con matrículas deberíamos de
determinar que cada chasis solo puede tener una matrícula (y cada matrícula un
chasis, ni más en ningún caso).

Figura N° 10: Relación de Uno a Uno

Uno a varios o varios a uno: determina que un registro de una entidad puede estar
relacionado con varios de otra entidad, pero en esta entidad existir solo una vez.
Como ha sido en el caso anterior del trabajador del taller.

Varios a varios: determina que una entidad puede relacionarse con otra con
ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser
reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios
coches distintos.

Los indicadores numéricos indican el primero el número mínimo de registros en una

relación y posteriormente el máximo (si no hay límite se representa con una "n").

Claves
Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de
los demás registros (no permitiendo que el atributo específico se repita en la entidad)
o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos
son los distintos tipos:

Superclave: aplica una clave o restricción a varios atributos de la entidad, para así
asegurarse que en su conjunto no se repitan varias veces y así no poder entrar en
dudas al querer identificar un registro.

25
 Database Foundations (Oracle)

Clave primaria: identifica inequívocamente un solo atributo no permitiendo que se

repita en la misma entidad. Como sería la matrícula o el número de chasis de un
coche (no puede existir dos veces el mismo).

Clave externa o clave foránea: este campo tiene que estar estrictamente
relacionado con la clave primaria de otra entidad, para así exigir que exista
previamente ese clave. Anteriormente hemos hablado de ello cuando
comentábamos que un empleado indispensablemente tiene que tener un cargo (que
lo hemos representado numéricamente), por lo cual si intentásemos darle un cargo
inexistente el gestor de bases de datos nos devolvería un error.

Figura N° 11: Modelo Entidad - Relación

26
 Database Foundations (Oracle)

TAREA N°03

Creación de Interfaces y Modelos Físicos en Oracle SQL Developer Data Modeler

Modelado de datos con Oracle SQL Developer

Oracle SQL Developer Data Modeler es una herramienta gráfica gratuita que mejora
la productividad y simplifica las tareas de modelado de datos. Con Oracle SQL
Developer Data Modeler, los usuarios pueden crear, navegar y editar modelos
lógicos, relacionales, físicos, multidimensionales y de tipo de datos. El Data Modeler
proporciona capacidades de ingeniería directa e inversa y apoya el desarrollo
colaborativo a través del control de código fuente integrado. El Data Modeler se
puede utilizar tanto en entornos tradicionales como en la nube.

Para emplear SQL Data Modeler, ejecutar las siguientes instrucciones:

1. Ejecutar ORACLE SQL DEVELOPER.

2. Click en menú Ver>Data Modeler>Explorador.

Figura N° 12: Uso SQL Data Modeler – Paso 02

3. Se visualiza el panel Explorador como panel izquierdo.

Figura N° 13: Uso SQL Data Modeler – Paso 03

4. Click con el botón secundario en Sin título_1 y seleccionar Guardar Diseño.

Figura N° 14: Uso SQL Data Modeler – Paso 04

27
 Database Foundations (Oracle)

5. Desplegar el nodo del diseño Desarrollo.

Figura N° 15: Uso SQL Data Modeler – Paso 05

6. Desplegar el nodo Modelos Relacionales y seleccionar Relational_1, con el botón

secundario del mouse seleccionar Mostrar.

Figura N° 16: Uso SQL Data Modeler – Paso 06

En la barra de herramientas se adicionará la barra siguiente:

Figura N° 17: Uso SQL Data Modeler – Paso 06

Y se abre una nueva pestaña.

Figura N° 18: Uso SQL Data Modeler – Paso 06

7. De la barra Relational Model seleccionar el icono Tabla y llevarlo sobre el área de

trabajo haciendo click sobre ella.

28
 Database Foundations (Oracle)

8. Llenar como Nombre: Programas

Figura N° 19: Uso SQL Data Modeler – Paso 08

9. Click en Columnas del panel izquierdo.

Figura N° 20: Uso SQL Data Modeler – Paso 09

10. Click sobre el botón Más de la pestaña Detalles.

Figura N° 21: Uso SQL Data Modeler – Paso 10

11. Llenar el nombre del programa con programa_id.

Click en Lógica.
En Tipo de Origen seleccionar Integer.
Click en la casilla Clave Primaria.

29
 Database Foundations (Oracle)

Figura N° 22: Uso SQL Data Modeler – Paso 11

Agregar el campo de cada una de las siguientes imágenes:

Figura N° 23: Uso SQL Data Modeler – Paso 11

Figura N° 24: Uso SQL Data Modeler – Paso 11

30
 Database Foundations (Oracle)

Figura N° 25: Uso SQL Data Modeler – Paso 11

Figura N° 26: Uso SQL Data Modeler – Paso 11

12. Click en Aceptar.

Figura N° 27: Uso SQL Data Modeler – Paso 12

Figura N° 28: Uso SQL Data Modeler – Paso 12

31
 Database Foundations (Oracle)

13. Click en Nueva Tabla.

14. La tabla contendrá los campos de la imagen siguiente:

Figura N° 29: Uso SQL Data Modeler – Paso 14

15. Click en Clave Primaria. Seleccionar los campos programa_id y nro_version.

Figura N° 30: Uso SQL Data Modeler – Paso 15

16. Click en el botón Agregar

Figura N° 31: Uso SQL Data Modeler – Paso 16

32
 Database Foundations (Oracle)

17. Click en Clave Ajena.

En la columna Nombre: Programa_FK.

Seleccionar del cuadro combinado Tabla de Referencias: Programas.
Seleccionar del cuadro combinado Restricción de Referencias: Programas_PK.
Columna de Referencia: programa_id.
Columna: programa_id.
Obligatoria: Check.

Figura N° 32: Uso SQL Data Modeler – Paso 17

18. Click en Aceptar.

Figura N° 33: Uso SQL Data Modeler – Paso 18

33
 Database Foundations (Oracle)

19. Seleccionar Desarrollador del Explorador de modelos y Click en Guardar Diseño.

Figura N° 34: Uso SQL Data Modeler – Paso 19

20. Click en Generar DDL de la barra de herramientas.

21. Seleccionar la versión de Oracle donde implementará el script.

Figura N° 35: Uso SQL Data Modeler – Paso 21

22. Click en Generar

Figura N° 36: Uso SQL Data Modeler – Paso 22

34
 Database Foundations (Oracle)

23. Click en Aceptar.

Figura N° 37: Uso SQL Data Modeler – Paso 23

24. Se generará el guión SQL. Hacer click en Guardar.

Figura N° 38: Uso SQL Data Modeler – Paso 24

25. Guardar el archivo en una carpeta y click en Guardar.

35
 Database Foundations (Oracle)

Figura N° 39: Uso SQL Data Modeler – Paso 25

Figura N° 40: Uso SQL Data Modeler – Paso 25

26. En el panel de conexiones, seleccionar y abrir la conexión DESARROLLO o la de su

preferencia.

36
 Database Foundations (Oracle)

Figura N° 41: Uso SQL Data Modeler – Paso 26

27. Click en el menú Archivo>Abrir y seleccionar con doble clik el archivo con extensión
DDL.

Figura N° 42: Uso SQL Data Modeler – Paso 27

28. Click en Ejecutar Script o pulsar F5.

Figura N° 43: Uso SQL Data Modeler – Paso 28

37
 Database Foundations (Oracle)

29. Seleccionar la conexión. Click en Aceptar.

Figura N° 44: Uso SQL Data Modeler – Paso 29

Figura N° 45: Uso SQL Data Modeler – Paso 29

38
 Database Foundations (Oracle)

30. Expandir el nodo de la conexión empleada y expandir el nodo tablas para visualizar
las tablas creadas.

Figura N° 46: Uso SQL Data Modeler – Paso 30

39
 Database Foundations (Oracle)

TAREA N°04

Programar un Script para Creación de una Base de Datos con Estructura y Datos

Create Database: Sirve para crea una base de datos.

Desde el punto de vista físico, una base de datos es, para oracle, un conjunto de
ficheros, a saber:

• datafiles, ficheros de datos, definidos en la creación de la base de datos.

• log files, ficheros de log, definidos tambien en la creación de la base de datos.

• init.ora, fichero de texto que contiene los parámetros de configuración de la base

de datos.

• control files, ficheros de control, definidos en el init.ora

• password file, fichero con la password del BDA y los operadores (todos los
demas usuarios estan definidos en tablas).

Así para crear una base de datos, una vez instalado oracle, debemos seguir los
siguientes pasos:

Definir ORACLE_SID

ORACLE_HOME = E:\Oracle\Product\10.0.0
ORACLE_SID = GESTION

Crear el fichero INIT.ORA

C:\>ORACLE_HOME\database\initGESTION.ora

control_files =
(/path/to/control1.ctl,/path/to/control2.ctl,/path/to/control3.ctl)
undo_management = AUTO
undo_tablespace = UNDOTBS1
db_name = GESTION
db_block_size = 8192
sga_max_size = 1073741824
sga_target = 1073741824

Definir fichero de passwords

$ORACLE_HOME\bin\orapwd file=ORACLE_HOME\database\pwdGESTION.ora
password=oracle entries=10

40
 Database Foundations (Oracle)

Podemos generar los pasos 2) y 3) con una sola instrucción:

oradim -new -sid GESTION -intpwd -maxusers 20 -startmode auto

-pfile E:\Oracle\Product\10.0.0\Database\initGESTION.ora

Arrancar la instancia

C:\>sqlplus / as sysdba
sql> startup nomount

Crea la base de datos con el nombre(o SID) GESTION y el char set

WE8ISO8859P1

CREATE DATABASE GESTION

LOGFILE 'E:\OraData\GESTION\LOG1GESTION.ORA' SIZE 2M,
'E:\OraData\GESTION\LOG2GESTION.ORA' SIZE 2M,
'E:\OraData\GESTION\LOG3GESTION.ORA' SIZE 2M,
'E:\OraData\GESTION\LOG4GESTION.ORA' SIZE 2M,
'E:\OraData\GESTION\LOG5GESTION.ORA' SIZE 2M
EXTENT MANAGEMENT LOCAL
MAXDATAFILES 100
DATAFILE 'E:\OraData\GESTION\SYS1GESTION.ORA' SIZE 50 M
DEFAULT TEMPORARY TABLESPACE temp TEMPFILE
'E:\OraData\GESTION\TEMP.ORA' SIZE 50 M
UNDO TABLESPACE undo DATAFILE 'E:\OraData\GESTION\UNDO.ORA' SIZE 50
M
NOARCHIVELOG
CHARACTER SET WE8ISO8859P1;

Ejecutar sql de creación: catalog.sql y catproc.sql

Sintaxis completa:

CREATE DATABASE nombreDB opciones

Donde las opciones:

DATAFILE filespec AUTOEXTEND OFF

DATAFILE filespec AUTOEXTEND ON [NEXT int K | M] [MAXSIZE int K
| M]
MAXDATAFILES int
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE tablespace [TEMPFILE filespec]
[EXTENT MANAGEMENT LOCAL]
[UNIFORM [SIZE int K | M]]
UNDO TABLESPACE tablespace [DATAFILE filespec]
LOGFILE [GROUP int] filespec
MAXLOGFILES int
MAXLOGMEMBERS int
MAXLOGHISTORY int
MAXINSTANCES int
ARCHIVELOG | NOARCHIVELOG
CONTROLFILE REUSE

41
 Database Foundations (Oracle)

CHARACTER SET charset

NATIONAL CHARACTER SET charset
SET TIMEZONE = 'time_zone_region'
SET TIMEZONE = '{+|-} hh:mm'
FORCE LOGGING
USER SYS IDENTIFIED BY password
USER SYSTEM IDENTIFIED BY password

Se puede poner mas de un DATAFILE o LOGFILE separando los nombres de fichero

con comas DATAFILE filespec1, filespec2, filespec3

Si no se especifican claves, Oracle establece "change_on_install" para SYS y

"manager" para SYSTEM.

Después de crear la base de datos podemos cambiar entre los modos

ARCHIVELOG, NOARCHIVELOG con la sentencia ALTER DATABASE.

Construcción de scripts Oracle SQL con ayuda del diccionario

Es bastante habitual si se trabaja con bases de datos que a menudo se tenga que
realizar alguna tarea de creación o alteración de estructuras, análisis, recompilación,
etc. sobre objetos de la base de datos. Para ello se suele crear un script con
numerosas sentencias DDL, en las que la mayoría de las veces lo único que cambia
es el nombre del objeto a tratar.

Crear sentencia Oracle SQL que genera sentencias Oracle

En estos casos puede ahorrarnos mucho trabajo la utilización del diccionario de la

base de datos para construir estas sentencias dinámicamente. Pondremos como
ejemplo la creación de un nuevo campo para almacenar la fecha de creación de los
registros en todas las tablas de un esquema de una base de datos ORACLE. Para
ello utilizaríamos la siguiente sentencia de SQL Oracle:

SELECT 'ALTER TABLE ' || OWNER || '.' || TABLE_NAME || ' ADD

FECHA_CREACION DATE DEFAULT SYSDATE;'
FROM ALL_TABLES WHERE OWNER ='HR';

El resultado de esta sentencia SQL Oracle sería algo como esto, las sentencias SQL
que queremos utilizar en realidad:

ALTER TABLE HR.DEPARTMENTS ADD FECHA_CREACION DATE DEFAULT SYSDATE;

ALTER TABLE HR.EMPLOYEES ADD FECHA_CREACION DATE DEFAULT SYSDATE;

Crear script con Oracle SQL para ejecutar sentencias SQL

Ahora sólo restaría guardar estas sentencias en un script y ejecutarlo, o lanzarlas

directamente desde la aplicación que utilicemos para interactuar con nuestra base
de datos.

Para el que tenga que (o prefiera) trabajar desde un terminal o linea de comandos,
la manera de hacer esto mismo con SQLPLUS sería la siguiente:

42
 Database Foundations (Oracle)

SQL> SET HEADING OFF

SQL> SET FEEDBACK OFF

Y finalmente ejecutar el script generado, aunque es recomendable una revisión

previa de las sentencias generadas:

SQL> @C:\campo_auditoria.sql

43
 Database Foundations (Oracle)

REFERENCIAS BIBLIOGRÁFÍCAS
Referencia N° 01:
Oracle Academy. (2023). Plan de Estudios de Database Oracle. Preparado para la
universidad y enfocado en el desarrollo profesional.
https://academy.oracle.com/es/solutions-curriculum-database.html

Referencia N° 02:
Oracle Academy. (2023). Certificaciones profesionales. Marque la diferencia y
destáquese con certificaciones profesionales.
https://academy.oracle.com/es/resources-oracle-certifications.html

Referencia N° 03:
Vega Munguia, Elio. (31 de mayo del 2022) Guía para docentes UNAM en Oracle
Academy.
https://docencia.tic.unam.mx/manual-academia/oracle/Inscripcion_cursos_oracle.pdf

Referencia N° 04:
Tutoriales Ya. (6 de junio del 2023). Oracle Ya desde CERO.
https://www.tutorialesprogramacionya.com/oracleya/

Referencia N° 05:
ORACLE. (11 de noviembre del 2023). Uso de la hoja de trabajo SQL en SQL
Developer para la sintaxis básica de SQL.
https://www.oracle.com/pe/tools/technologies/howto-sql-worksheet-basic-syntax.html

Referencia N° 06:
JORGESANCHEZ.NET. (23 de octubre del 2021). Manual de SQL (Oracle SQL).
https://jorgesanchez.net/manuales/sql/intro-sql-sql2016.html

Referencia N° 07:
DESARROLLOWEB.COM (1 de abril del 2023). Tutorial de Oracle.
https://desarrolloweb.com/manuales/tutorial-oracle.html

Referencia N° 08:
Ruiz de Miras, Juan. (10 de enero del 2020). Tutorial Oracle SQL Developer 1.2.1.
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf

44
 Database Foundations (Oracle)

REFERENCIAS DE IMÁGENES
Figura N° 01: Formas Normales
https://mundoinfotech.wordpress.com/2015/02/07/formas-normales-normalizacion-de-
base-de-datos/
Figura N° 02: Flujo de actividades
https://mundoinfotech.wordpress.com/2015/02/07/formas-normales-normalizacion-de-
base-de-datos/
Figura N° 03: Esquema modelo base de datos relacional
https://ayudaleyprotecciondatos.es/bases-de-datos/modelos/
Figura N° 04: Esquema modelo base de datos jerárquico
https://ayudaleyprotecciondatos.es/bases-de-datos/modelos/
Figura N° 05: Esquema modelo base de datos en red
https://ayudaleyprotecciondatos.es/bases-de-datos/modelos/
Figura N° 06: Esquema modelo base de datos orientados a objetos
https://ayudaleyprotecciondatos.es/bases-de-datos/modelos/
Figura N° 07: Esquema modelo base de datos entidad relación
https://ayudaleyprotecciondatos.es/bases-de-datos/modelos/
Figura N° 08: Esquema modelo base de datos plano
https://ayudaleyprotecciondatos.es/bases-de-datos/modelos/
Figura N° 09: Optimizar y repetir el modelo de datos
https://aws.amazon.com/es/what-is/data-modeling/
Figura N° 10: Relación de Uno a Uno
https://www.genbeta.com/desarrollo/fundamento-de-las-bases-de-datos-modelo-entidad-
relacion
Figura N° 11: Modelo Entidad Relación
https://www.genbeta.com/desarrollo/fundamento-de-las-bases-de-datos-modelo-entidad-
relacion
Figura N° 12: Uso SQL Data Modeler – Paso 02
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 13: Uso SQL Data Modeler – Paso 03
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 14: Uso SQL Data Modeler – Paso 04
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 15: Uso SQL Data Modeler – Paso 05
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 16: Uso SQL Data Modeler – Paso 06
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 17: Uso SQL Data Modeler – Paso 06
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf

45
 Database Foundations (Oracle)

Figura N° 18: Uso SQL Data Modeler – Paso 06

http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 19: Uso SQL Data Modeler – Paso 08
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 20: Uso SQL Data Modeler – Paso 09
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 21: Uso SQL Data Modeler – Paso 10
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 22: Uso SQL Data Modeler – Paso 11
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 23: Uso SQL Data Modeler – Paso 11
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 24: Uso SQL Data Modeler – Paso 11
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 25: Uso SQL Data Modeler – Paso 11
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 26: Uso SQL Data Modeler – Paso 11
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 27: Uso SQL Data Modeler – Paso 12
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 28: Uso SQL Data Modeler – Paso 12
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 29: Uso SQL Data Modeler – Paso 14
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 30: Uso SQL Data Modeler – Paso 15
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 31: Uso SQL Data Modeler – Paso 16
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 32: Uso SQL Data Modeler – Paso 17
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 33: Uso SQL Data Modeler – Paso 18
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 34: Uso SQL Data Modeler – Paso 19
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 35: Uso SQL Data Modeler – Paso 21
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 36: Uso SQL Data Modeler – Paso 22
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 37: Uso SQL Data Modeler – Paso 23

46
 Database Foundations (Oracle)

http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 38: Uso SQL Data Modeler – Paso 24
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 39: Uso SQL Data Modeler – Paso 25
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 40: Uso SQL Data Modeler – Paso 25
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 41: Uso SQL Data Modeler – Paso 26
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 42: Uso SQL Data Modeler – Paso 27
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 43: Uso SQL Data Modeler – Paso 28
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 44: Uso SQL Data Modeler – Paso 29
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 45: Uso SQL Data Modeler – Paso 29
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf
Figura N° 46: Uso SQL Data Modeler – Paso 30
http://www.v-espino.com/~chema/daw1/tutoriales/oracle/sqldeveloper2.pdf

47