1026284730 

05/02/2020 – Clase N°1

“Bases de datos”

Jhon Jairo Londoño P.

jlondonop1@ucentral.edu.
co Ingeniero/Especializ
RAVD/ Magister T.I.
(Docente UD Posgrado/Pregrado/Docente
UC) Libros:
✔ Modelo seudomatemático para el Diseño de las bases de datos relacionales
✔ Teoría de Sistemas Enfoque Sistémico
✔ Ingeniería de Software Enfoque práctico

“Contenido temático”

1) Definición general de las BD/Conceptos y Escenarios

2) Definición de Sistema y Construcción del “Contexto” con base en la lógica de las clases.

3) Contexto Monofuncional Simple y Monofuncional Compuesto del Sistema:

- Modelo Dependencias Funcionales (Construcción de

Conjuntos): Dependencia Funcional Exclusiva (DFE)
Dependencia Funcional No Exclusiva (DFNE)

Leyes de Armstrong (Cálculo

Relacional) Normalización:
1FN
2FN DFE
3 FN
4 FN DFNE
5 FN

4) Contexto Multifuncional Simple y Multifuncional Compuesto

5) Programación básica y avanzada con PLSQL:

- Inner Join
- Subconsultas
- Procedimientos Almacenados:
● Cursores
● Trigger

6) Tranzabilidad de Congruencia entre el diseño de bases de la base de datos, y el

diseño de software implementando Diagramas CASOS USO, Secuencia clases y
Formato Requerimientos Funcionales.

Compromiso curso:

✔ Presencialidad
✔ Respeto
✔ Cumplimiento en trabajos
✔ Actitud y atención en clase

(Disciplina) Forma de Calificaciones:

✔ Documento o Memorias de la materia 40% Edición en Word de cada una

de las clases (lo que
escribe el profesor) /
trabajos en casa y en
clase / cada temática con
una conclusión mínima en
5 líneas.

✔ Apreciativa del Rendimiento 30%

✔ Evaluación individual 30%

100% de cada

corte
 Conclusiones: En la presentación del curso de Bases de Datos se supo el
Contenido temático, el compromiso del curso y la forma de calificaciones. Las
bases de datos no se empiezan programándolas, sino que antes de llegar a ese
punto deben ser pensadas “modeladas” para que cuando llegue el instante en
que se acuda al motor de desarrollo con el cual crear la base de datos, se haya
previamente analizado el papel de la base de datos en la funcionalidad del
programa.

8/02/2020 – Clase N°2

✔ Conceptos Generales/Definición/Escenarios:

Cuando se habla de Bases de Datos, se debe involucrar varios escenarios, y estos son:

- El sistema

- El diseño

- El motor

- La gestión

El sistema es entonces la materia prima para poder acceder al Diseño de la Base

de Datos y por supuesto al Diseño de Software.

Desde la perspectiva de la Ingeniería de Software el “Sistema” deberá ser

concebido como el escenario encargado de contener la “Lógica de los procesos” a
través de los cuales se maneja la información que permitirá cumplir con los
propósitos “misionales” de las diferentes “áreas” que hacen parte de la
“organización” de la empresa.

Antes de pensar en el Diseño de Software, se deberá pensar en el Diseño de la

Base de Datos, queriendo con esto decir que, a través de la elaboración de los
programas que hacen parte del producto de software, se hará posible conducir la
información a la Base de Datos.

El “Diseño” de la Base de Datos, es el segundo Escenario relacionado con las

generalidades de las Bases de Datos, y tiene por objeto, organizar la información
dentro de un “Repositorio” o espacio, de manera funcional y racional, utilizando
las aplicaciones de metodologías y técnicas dispuestas para garantizar el buen
uso de la información.
Sobre el “Diseño” hay que decir que existen 2 tipos de diseños:
 - Diseño Relacional

El Diseño Relacional se utiliza para atender negocios de sistemas

“transaccionales”, en donde la tecnología de estas Bases de Datos, colaboran con
validar la información a fin de evitar “redundancias” y evitar el ingreso de
información desarticulada, sin tener que recurrir a los desgastes de la
programación.

- Diseño Documental

El Diseño Documental, se utiliza para atender negocios de sistemas “No

transaccionales”, en donde la validación y articulación de la información no es
importante y por tanto permite la “redundancia de la información”, aunque exija
de la identificación de lo grabado a través de la elección de un “campo clave”. Es
posible vincular los conceptos de la validación, articulación y no redundancia de la
información incorporando esfuerzos de tiempo de programación.

Bases de Datos Relacional Bases de Datos Documental

Céd Nomb Profesi

Cla Documento
ula re ón
ve
10 María 2 30 30,Pedro,2,Aboga
20 Juan 1 do
30 Pedro 2 20 20,Juan,1,Médico
40 Ruth 1 10 10,María,2,Aboga
Tabla 1 Vecto
Tabla 3
r

Profesión Descripció String: Archivo plano

n
1 Médico
2 Abogado

Tabla 2
Cuando el Diseño corresponde a una Base de Datos Relacional, hay que
anteponer un “Modelado” previo, que se relaciona con el “Modelo Conceptual” y
que está de la mano con el denominado “Modelo Entidad-Relación MER”, creado
por Peter Chenn; este modelo se apoya desde luego en la “Lógica del Negocio
del Sistema” y sustentado en la denominada “Ley de la Autodeterminación” y “Ley
de la Reflexividad” propuesta por Armstrong, permite representar las “Clases” del
sistema como “Entidades” y la articulación de las Entidades como “Relaciones”,
de una manera muy gráfica, pero obedeciendo una metodología.

El “Motor” de la Base de Datos, es el instrumento con base en el cual se hace

posible llevar el “Diseño” al computador.

Es el “Motor” de la “BD” equiparable a un lenguaje de computador, por tanto, su

utilización solo es válida, cuando se ha construido un Diseño lógico de la Base
de Datos, con lo cual se define el orden de grabación de los datos y en
consecuencia el orden de cómo acceder a los mismos.

Existen 2 grandes vertientes para el uso de Motor de la Base de Datos Relacional:

1 – Creación de las tablas del Diseño

2 – Manejo de datos dentro de las tablas

La “Gestión” es el escenario que se compromete con el uso de la información a

través de un lenguaje relacionado con el motor.

Lenguajes de las Bases de Datos Relacionales, los cuales van de la mano con el
“Motor” encontramos: MySQL, SQLServer, Oracle, y otros, los cuales se
fundamentan en unas cláusulas y directivas estándares, que cambian muy poco
dependiendo del motor.

Si bien el lenguaje se empieza a usar desde el mismo momento en que se crean

dentro del computador las tablas del diseño (create table), se hace más
interesante cuando se gestiona la información de la Base de Datos, a través de
instrucciones tales como:

- Insert

- Update

- Delete

- Select

Lo anterior trasciende cuando se incurre en la programación a través de:

- Procedimientos Almacenados elementales

- Procedimientos Almacenados en cursores

- Procedimientos Almacenados con Trigger

Conclusiones: El diseño de las bases de datos se hace desde el sistema
que de la definición de Ingeniería de Software es el escenario que contiene
la “Lógica de procesos”. Esta lógica permite manipular la información
acorde a la misión de la empresa, lo que hace garante su existencia. El
Diseño de las bases de datos va primero porque, la base de datos es la
encargada de tener la información organizada (Repositorio) que el software
le brindará y de la que hará uso, siendo la información usada
funcionalmente. Se hace uso del diseño relacional de las bases de datos
cuando el negocio tiene sistemas transaccionales, o sea, la información
está en constante flujo y modificación, y en este diseño se recurre al evitar
desarticulación como redundancia en la información; por otro lado, el
diseño documental de bases de datos es donde el sistema de un negocio
no es transaccional, o sea, puede incurrir en la redundancia.

El diseño de una base de datos relacional requiere de un modelado el cual

se hace mediante el Modelo conceptual y seguido de este el Modelo
Entidad Relación. El MER lo creó Peter Chenn y se defina por la Ley de
Autodeterminación (Asignación de atributos) y lo que se conoce como
“Clases” el modelo lo expone como “Entidades”, y cada una puede estar
relacionada con otras (Articulación de Entidades); este modelo es
totalmente gráfico, lo que facilita su entendimiento.
Por último el motor que es como el lenguaje de programación es la
implementación del diseño de la base de datos, esto quiere decir que su
uso solo se justifica si al menos se cuenta con el diseño.

El motor sucede en dos partes: Creación de tablas de diseño y el manejo

de datos dentro de las tablas. En esta fase de la base de datos se lleva al
computador todo lo sucedido en las fases previas, que quedó como el
Diseño de la Base de Datos.
 12 /02/2020 – Clase N°3

- Definición del sistema y construcción del contexto con base en la lógica del negocio

Un sistema desde la perspectiva de la Ingeniería de Sistemas se debe concebir

como un escenario compuesto por la Entrada, Proceso y Salida, en donde en
cada uno de estos elementos prima la lógica que se relaciona con los diferentes
procedimientos que hacen parte de su manejo:

Son los

“Procedimientos” entonces, los encargados de sugerir una

sistematización o automatización de los datos obedeciendo a un
“Contexto”.

El “Contexto” define la dimensión de lo que se debe hacer, por tanto, define el

“largo y ancho” de lo que se desea.

Para definir el “Contexto”, se parte de la “Narrativa” de necesidades del

“Cliente”, con base en la cual se sucederán los siguientes incidentes:

- Lectura

- Abstracción

- Modelo de la lógica
 Narrativa del cliente

Lectura y abstracción:

1. Qué se quiere controlar

2. Para quien se va a controlar

Modelo de la lógica

Clase 1 y Clase 2: Son los escenarios que se quieren controlar de la lógica, los cuales en términos
de la Ingeniería de Software, se denominan “Clases”.

Ejemplo:

La compañía XXX dedicada como objeto social a la “Venta de calzado”, fue creada
en …, domiciliado en …, con un capital de $... .

La compañía está interesada en “Controlar a través del computador las facturas que se
producen por las compras efectuadas por los clientes”, de esta manera se facilitará a los
vendedores y ejecutivos mantener una relación más directa con los productos y los
clientes, etc.
Téngase en cuenta que los sistemas en su expresión absoluta, sin pensar en el
computador, se hallan dentro de los sectores productivos de la economía:

- Primario: Recursos naturales, Agro, Ganadería, Piscicultura, etc.

- Secundario: Industria (Maquinaria, Explotación u Transformación)
- Terciario: Logística y servicios (Educación, Médicos, Transporte, Energía)

Gestiona y administra el
sector primario y Comercialización
Aprovecha al secundario
sector primario
Ejemplo:

Una empresa dedicada al área de la construcción tiene un equipo de trabajo que se

relaciona con la operación de máquinas excavadoras.

La empresa funciona en un edificio de 4 pisos ubicado en un sector elegante de la

ciudad, además goza de la presencia de bellas secretarias, las cuales atienden de
manera decorosa y profesional a los clientes.

Los clientes son constructores de obras civiles los cuales de manera permanente
alquilan equipos y maquinarias para la excavación de terrenos. El alquiler de los equipos
se sucede a través de un contrato de prestación de servicios, lo cual ha motivado a la
empresa a construir una solución informática que controle las maquinarias prestadas a
través de los contratos suscritos con los clientes.

El Departamento de Contabilidad reclama con urgencia conocer de manera rápida y

virtual la cantidad de contratos y los diferentes tipos de equipos y maquinarias
alquiladas por los clientes.

Conclusiones: El contexto es primordial para el Diseño de una Base de Datos como de

Software, ya que delimita lo que se quiere, cosa que brindan los procedimientos del
sistema (elementos relacionados lógicamente de un sistema en los sectores productivos)
con lo cual se pueda entender la lógica del negocio que está sujeta a la narrativa del
cliente; pese a que a veces en esta narrativa toda la información parezca ser relevante, no
toda lo es, porque hay datos que solo son informativos (no aportan a la lógica del
negocio), o sea no ayudan a identificar ni lo que se quiere controlar o para quien se va a
controlar, ya que estas dos ideas son clave para armar el contexto de la base de datos.
19/02/2020 – Clase N°4

- Contexto del Sistema/Primera Forma Normal 1FN y Segunda Forma Normal 2FN -

Está claro que solo se procede a construir el Diseño de la Base y el Diseño de Software, si
existe el contexto del sistema.

Con base en el “Contexto” se construye una expresión “exacta” de la lógica del negocio
(del sistema), compuesta por las “Clases principales”, como sigue:

Se construye de abajo hacia arriba y se lee de arriba hacia abajo:

Lectura: Existen muchos (m) clientes, y cada uno (1) de los clientes tiene muchas (m) facturas.

Entre las “Clases” del contexto de un sistema siempre se define de “arriba hacia
abajo”, una Relación (R) de uno (1) a muchos (m); esta Relación (R) se denomina
“Relación Natural”.

Los “Contextos” dependiendo de la abstracción que se suceda a partir de la “Narrativa” de los

clientes, podrán ser:

1. Monofuncional Simple:

2. Monofuncional Extendido
3. Multifuncional Simple:

4. Multifuncional Extendido:
Nota: La representación se puede relacionar con la (Representación tradicional)

-Diseño de la Base de Datos/Normalización (1FN-2FN)-

El Diseño de BDR parte de un número impositivo del “Contexto” del sistema.

La Normalización es un ejercicio, que permite garantizar la “No Redundancia” de la

información, la “funcionalidad” de servicios entre los datos, la “Navegación” coherente y
lógica entre los escenarios de la información.

Para cumplir con lo anterior, se habla de las siguientes Formas Normales FN:

✔ Primera Forma Normal 1FN:

Se dice que el Diseño de una BD Relacional se encuentra en 1FN, cuando existe el

Contexto del Sistema y cuando hace presencia la “Ley de Autodeterminación” de
Armstrong, que consiste en asignar atributos a cada una de las clases del
contexto, de manera “Absoluta” (que los atributos o nombres de los datos de una
clase determinada, son de esa clase y no de otras)
Pasos

1. Elegir el “atributo identificador” de c/u de las clases del contexto, que se denominarán “llaves
primarias” (Primary keys - PK)

2. Elegir los “atributos” que se pueden expresar como “códigos” dentro de cada una
de las clases, estas se llamarán “llaves secundarias” ó “llaves foráneas FK”, si las
llaves secundarias son identificadas desde el mismo momento de la
“Autodeterminación”, las llamaremos “Foreign Key por defecto DFK”

Conclusiones: Luego de tener el contexto del sistema (escenario limitado que

se abstrae de la narrativa del cliente), este se modela acorde con algún tipo de
contexto (expresión), en donde cualquier contexto se lee de arriba hacia abajo y
se crea desde lo que se busca controlar hasta para quien se va a controlar.

Los contextos manejan la relación (R) que se conoce como Relación Natural
relación que se da cuando entre en la multiplicidad leyendo el contexto, la relación
de las dos
“Entidades” es uno a muchos. Esto significa que en la lectura del contexto la clase
antecesora es de (1) y la sucesora de muchos (m). La relación entre “Entidades”
se asemeja a la herencia de “Clases” en UML. Hecho eso, se procede con la
Normalización, que es una práctica que garantiza la “No Redundancia”,
“funcionalidad” y “navegabilidad” en la información del sistema. En la primera
forma normal se asignan los atributos propios de cada clase (nombres), o sea, de
forma “Absoluta”; dentro de los atributos se buscan cual puede ser llave primaria
y cuales las llaves secundarias, toda esta forma normal, regida por la “Ley de
Autoderminación” de Armstrong.
22 /02/2020 – Clase N°5

-Contexto y
Normalización 1FN –
2FN-

Contexto: Identificación y articulación de clases (Qué se va a controlar – Para quien se va

a controlar)

Normalización:

Primera Forma Normal (1FN):

- Identificación y asignación de “atributos” por la ley de la “Autodeterminación”

de Armstrong.
- Identificación de llaves primarias (una PK por cada clase) /Identificación de llaves foráneas
o secundarias por defecto (FKD) que son aquellos atributos tipo “códigos”.
Segunda Forma Normal (2FN):

- Definición del tipo de Dependencia Funcional -DF, que corresponde a una Relación
Inversa que se sucede de abajo hacia arriba, es decir entre la “Clase sucesora” y la
“Clase predecesora”.

Las Dependencias Funcionales también de Armstrong, pueden ser de 2 tipos:

a. Dependencia Funcional Exclusiva – DFE:

Cuando existiendo una “Relación Natural” de una (1) a muchas (m) se obtiene una
“Relación Inversa” de uno (1) a uno (1).
Ejemplos:

i. (Muchos clientes) cada uno (1) de los muchos clientes tiene

muchas (m) facturas = Relación Natural

ii. Cada una (1) de las muchas facturas son de ese (1) cliente y
no de otros = Relación Inversa

b. Dependencia Funcional No Exclusiva – DFNE:

Cuando existiendo una “Relación Natural” de uno (1) a muchos (m), se obtiene una
“Relación Inversa” de uno (1) a muchos (m).

Ejemplos:

i. (Muchas facturas) cada una (1) de las muchas (m) facturas, tiene
muchos (m) artículos = Relación Natural

ii. Cada uno (1) de los muchos (m) artículos de cada una de las
muchas facturas, pueden estar también en otras muchas (m)
facturas.
 - Modelo Matemático de las BD -

Es un escenario fundamentado en la teoría de conjuntos, que permite solucionar los

tipos de Dependencias Funcionales vinculados en la “articulación de clases”.

DFE (Contexto: Sin artículos)

FKD (Foreign Key por Defecto): Son aquellos atributos que desde la
autodeterminación se manifiestan como posibles “códigos”.

El Modelo Matemático es posible si se tiene 1FN y 2FN, conduce a expresar en forma de

conjuntos el “Diseño de la BD” solucionando (3FN-4FN-5FN) los tipos de Dependencias
Funcionales vinculadas entre las “Clases” de arriba hacia abajo.

1 Conjunto de la Clase Principal Clientes

{idcli (PK), nom, fechnac, lugnac (FKD)}

2 Conjunto de la Clase Secundaria Lugares:

{lugnac (PKE – Primary Key Emergente), nomlug}

3 Conjunto de la Clase Principal Facturas: “Solucionar la DFE”

{nofac (PK), fechfac, valtot, sucur (FKD), idcli (FKP – Foreign Key por Proceso)}

4 Conjunto de la Clase Secundaria Sucursales:

{sucur (PKE – Primary Key Emergente), dir, tel}

FKD (Foreign Key por Proceso): Una foreign key por proceso siempre solucionará en
modo conjunto la clase sucesora que se encuentre en DFE (Dependencia Funcional
Exclusiva) con la clase predecesora.

Lo anterior muestra de que manera la PK de la clase antecesora se refleja como Foreign

Key por Proceso en la clase sucesora a esto se le llama Reflexividad (Ley de
Reflexividad de Armstrong).

El tipo de dependencia funcional exclusiva siempre nos conducirá a la tercera forma

normal 3 FN y no existirá la posibilidad de una cuarta y quinta forma normal, porque estas
formas normales son propias de las dependencias funcionales no exclusivas.

La utilización del modelo conceptual (Entidad-Relación de Peter Chenn) y del Modelo

Relacional (Edgar Codd) solo serán posibles si existe el Modelo de Solución
Matemático.

Conclusiones: Ya establecido un contexto, entra la Normalización; este proceso está

dividido en 5 partes que se llaman formas normales. La primera forma normal consiste en
asignar los atributos de forma “Absoluta” (Atributos solo de la Entidad) de cada una de las
“Entidades” y de ellos identificar la llave primaria y las llaves secundarias. La llave
primaria es la que identifica a cada “Entidad”, mientras que las secundarias son las que se
ven como posibles “códigos”.

En la segunda forma normal se identifica el tipo de dependencia funcional que se da entre

las “Entidades”, esto se hace leyendo de abajo hacia arriba el contexto (la multiplicidad de
clases). Si la multiplicidad por la relación inversa viene dada de uno (1) a uno (1) esto
quiere decir que es una Dependencia Funcional Exclusiva. En caso tal de que la relación
inversa sea uno (1) a muchos (m), sería una Dependencia Funcional No Exclusiva.

Ya armadas la 1FN y 2FN, se puede realizar si la dependencia funcional es exclusiva, la

3FN. La 4 y 5FN se hacen solamente cuando la dependencia funcional es no exclusiva.
Como ya se hizo la 1FN y 2FN es posible realizar el Modelo seudomatemático, el cual es
expresar en forma de conjuntos (inspirado por la Teoría de conjuntos en Matemáticas) las
“Entidades” escribiendo entre corchetes todos los atributos y si es una PK o FKD cierto
atributo y se deja pronunciado en el conjunto.
Teniendo en cuenta cual es la PK de la clase antecesora, esta se ve como la FKP (Foreign
Key por Proceso) en la clase sucesora, lo que permite resolver la dependencia funcional
exclusiva entre clases como lo fue entre la clase antecesora Clientes con la clase
sucesora Facturas; a esto se le conoce como “Ley de Reflexividad de Armstrong”. Una vez
hecho el Modelo seudomatemático se puede hacer el Modelo Conceptual de Peter Chenn
(Entidad-Relación) y el Modelo Relacional de Edgar Codd, de lo contrario no es posible.
 26 /02/2020 –
Clase N°6

Álgebra proposicional

Diseño Bases de
Datos

Antecedentes 1FN – 2FN:

1FN - Contexto Sistema

- Autodeterminación (Ley Armstrong)

2FN
- PK-FKD
- Asignar DF(E,NE)

Edgar (Leyes Armstrong)

Codd

✔ Construcción del Diseño: Resolver los tipos de

Reflexividad/Transitividad DFE Dependencias funcionales

FKP: PK de la clase antecesora que se refleja como FKP en la clase sucesora.

Representación de la Resolución de la Reflexividad (DFE)

- Modelo seudomatemático (Conjuntos)
- Modelo conceptual Evolucionado o Asegurado: Modelo Entidad Relación

Código

Clientes{idcli (PK), nom, fechnac, lugnac (FKD) }

Lugares {lugnac (PKE – Primary Key Emergente), nomlug}

Facturas {nofac (PK), fechfac, valtot, sucur (FKD), idcli (FKP – Foreign Key por Proceso)}
Sucursal {sucur (PKE – Primary Key Emergente), dir, tel}
 - Modelo Entidad-

Relación Reglas:

1. Inicia el modelo de izquierda a derecha ubicando en modo “entidad”, como primer

conjunto, el que resuelve la última clase del contexto

2. Ubique en modo entidad a la derecha de la entidad de la izquierda, el conjunto que

tiene la PK del FK de la entidad de la izquierda.

3. Asigne las Relaciones de derecha a izquierda

4. En adelante el modelo deberá ser leído de derecha a izquierda.

- Modelo Relacional (MR): Cumple las mismas reglas del MER, pero en modo “Tablas”
 - Modelo DDL (Lenguaje para Definición de Datos) / Motor

Scrip key(sucur)
t );

create Database

base1; use base1;

create table

lugares (

lugnac int,

nomlug

varchar(30),

primary

key(lugnac)

);

create table

clientes (

idcli int,

nomcli

varchar(20),

fechnac date,

lugnac int,

primary key(idcli),

foreign key(lugnac) references

lugares(lugnac)

);

create table

sucursales (

sucur int,

dir varchar(25),

primary
c (10),

r fechfac

e date, valtot

a int(12), idcli

t int, sucur

e int,

t primary key(nofac),

a foreign key(idcli) references clientes(idcli),

b foreign key(sucur) references

l sucursales(sucur)

e );

t
Conclusiones: Contando ya con un Modelo pseudomatemático, se parte a construir el
Modelo Entidad-Relación y el Modelo Relacional. El MER se hace organizando en un
esquema con las formas rectángulo (entidades), óvalo (atributos) y rombo (relaciones)
con líneas con el lado blanco hacia la derecha y el negro hacia la izquierda, dibujándose el
modelo de izquierda a derecha desde como conjunto inicial, la entidad que resolvió la
última clase del contexto con sus atributos, y sucesivamente hacia la derecha se van
poniendo las clases que tienen la PK de la FK de la clase de la izquierda (con sus
atributos) hasta quedar organizado.

Para el Modelo Relacional, se siguen las mismas prácticas que en el Modelo Entidad-
Relación, solo que esta vez en forma de tablas poniendo los atributos (campos) dentro de
la tabla y las relaciones se siguen por una línea que arranca con tres paticas desde la
clase que tiene la FK, hasta la que tiene el PK de la clase anterior.

Con todo lo anterior, ya se puede proceder a usar el motor para implementar el modelo
diseñado, se comienza con la creación de la base de datos con el comando create
database name; (con name como el nombre a escoger para la base de datos).

Luego para crear las entidades se usa el comando create table tbl1(); (con tbl1 como el
nombre a escoger para la entidad), para el motor las entidades son las tablas; se abre y
cierra paréntesis poniendo al final del de cierre un punto y coma. Adentro van todos los
atributos de cada clase, las PK se identifican con el comando primary key(atributo); (La
separación entre cada atributo se hace con una coma excepto en el último atributo de la
tabla). Las FK se identifican con el comando foreign key(name) references
entidadPK(name) (con entidadPK como la clase que contiene la PK de la FK), la FK de la
clase donde esta se coloca debe tener el mismo nombre que la PK en la clase a la que
hace referencia con references el comando.

No hay que olvidar que el motor es el paso menos importante, ya que lo que hizo que el
código funcionará fue el diseño, por eso al momento de ya escribir las líneas de código
no debe existir ningún error semántico (de lógica), la ingeniería vale por el pensamiento
y no solo por la técnica (programar) que para eso existen los técnicos.
29 /02/2020 – Clase N°7

Si un contexto tiene DFE y DFNE, la DFNE prima, por lo cual se debe llevar a 5FN la base de datos

-Notaciones UML- Notaciones Peter Chenn aplicado al DFE –

Notas:

 La lógica del core o núcleo del sistema la da el cliente

 La lógica de programación, los reportes (Inteligencia de negocios) la tiene el programador
 Las clases secundarias contribuyen a complementar las clases principales
 Las FKD son clases secundarias.
 La Base de Datos se hace con base en el core del negocio
UML: Asociación Bilateral Binaria – DFE

Peter Chenn: Disyunción o Desunión parcial DFE

Peter Chenn: Exclusividades FKD

DML (Lenguaje de Manejo de Datos) Básico: Insert (Grabar), Select (Leer), Delete, Update
“Primera captura de Datos”

use base1;

insert into lugares(lugnac,nomlug)

values(1, “Bogotá”);

insert into clientes(idcli, nomcli,

fechnac, lugnac)

values(100,’Pedro’,’1978-12-10’,1);

insert into sucursales(sucur,dir,tel)

values(10,’Av 6 Calle 40’, 4120);

insert into facturas(nofac, fechnac, valtot,

idcli, sucur)

values(204,’2019-10-08’, 400000, 100, 10);

select * from lugares;

select * from clientes;

select * from

sucursales; select *

from facturas;
Conclusiones: Existen algunas notaciones para saber la DFE o la FKD como lo son: La
Disyunción o Desunión parcial y las Exclusividades.

Luego de codificar las entidades (tablas) y sus atributos (PK, FK) con el uso del DDL, la
parte de la gestión de la base de datos comienza con el DML (Lenguaje de manejo de
datos). Recordando que la base de datos se conforma por: Sistema, diseño, motor y
gestión, esta última parte surge al ya haberse pensado el diseño como haberlo
implementado en el motor. La gestión se caracteriza por como su nombre lo indica
“gestionar”, o sea, manejar los datos de las tablas en la base de datos en función de la
lógica del negocio, ya que toda base de datos surge y sirve en función de la lógica del Core
o núcleo del sistema, que inicialmente como se vio en el contexto solo la tiene el cliente y
es inmutable por el programador. La lógica que sí puede pensar y hacer libremente el
programador es la lógica de reportes, que se trata de la forma de llegar a los resultados
que el cliente espera sin importar el modo en cómo se llegó a la solución de lo que planteó
la lógica del negocio, ahí si puede intervenir el programador; a esta lógica también se le
conoce como lógica de programación, la cual es totalmente distinta a la establecida por el
sistema del cliente, por ende un Ingeniero de Sistemas lo que no hace es crear sistemas
sino en cambio, automatizar los sistemas ya existentes.

Las clases secundarias no heredan nada porque ellas lo que hace es complementar a las
clases primarias, principalmente por ser solución de la Dependencia Funcional que haya
entre las clases principales, brindando los atributos que consolidan a estas clases como
las FKP o PKE necesarias.

A la hora de trabajar con el DML se usan varias instrucciones, algunas básicas son: Insert,
Delete, Select y Update. Estas instrucciones permiten hacer el manejo de los datos, por
ejemplo, Insert permite crear varias entidades llenando uno o todos sus campos
(atributos), Delete lo que hace es borrar lo ingresado, Select permite ver la información
existente de alguna o todas las instancias de una Entidad (identificadas por las PK), y
Update actualizar los campos existentes. Cuando se ingresan datos a esto se le llama
“Captura de datos”.