20191103201129895361 (1)

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.
pe
IIND-169, VI CICLO e-mail: elmer.gonzalez@fulbrightmail.org
VISTA DE LA INFORMACIÓN
Diseño de la Información
Es momento para describir una metodología en la
construcción de un modelo entidad-relación.
Las mejores prácticas de diseño de un modelo de
la información es mantener una mirada puesta en
su implementación como una base de datos
relacional.
INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe
Se presenta una introducción a SQL (Structured
Query Language), un lenguaje de consultas para
bases de datos relacionales.
Se explica como usar los cuatro comandos
necesarios SQL para Crear, Leer, Actualizar y
Eliminar datos.

Para entregar una base de datos de calidad, es
necesario que este sin redundancias y evitar las
anomalías de datos. Esto es realizado a través de
la Normalización.

En este capítulo aprenderá:
▪ Describir la metodología para construir un modelo E-R
▪ Resolver relaciones N:M en los modelos E-R
▪ Escribir 4 comandos SQL: SELECT, INSERT, UPDATE, y DELETE.
▪ Describir las anomalías de base de datos o databases que
pueden ocurrir.
▪ Normalizar un modelo de información a la 3NF
▪ Crear un diccionario de datos.

UNIDAD 04: Vista de la Información,
CAP. 13: DISEÑO DE LA INFORMACIÓN,
semanas 14-15: NOV 18 – 29

NRC: 1916, lunes 9:45 am → 11:30 am (Teoría: aula G409)
NRC: 1918, lunes 4:10 pm → 5:55 pm (Teoría: aula G403)
NRC: 7907, lunes 6:00 pm → 7:45 pm (Teoría: aula G403)
NRC: 1919, martes 6:00 pm → 9:35 pm (Práctica en el aula G409)

NRC: 3984, jueves 4:10 pm → 9:35 pm (Práctica en el aula G407)
NRC: 7908, viernes 4:10 pm → 7:45 pm (Práctica en el aula G402)
por: ELMER GONZALEZ HERRERA

Doctor en Ingeniería Industrial, PERÚ
Master of Science in Computer Science, USA
Ingeniero Industrial, PERÚ
e-mail: elmer.gonzalez@fulbrightmail.org

“¿Dónde está la vida que hemos perdido en vivir? ¿Dónde está la sabiduría que
hemos perdido en el conocimiento? ¿Dónde está el conocimiento que hemos
perdido en la INFORMACIÓN? – poeta T. S. Eliot (1888 – 1965)
Agenda
1. Método para Construir un Modelo E/R
2. La Base de Datos Relacional: SQL (structured query
language), Reglas de Base de Datos
3. Normalización
4. Resumen.

1. Método para Construir un Modelo E/R
▪ El modelo E/R puede ser desarrollado en dos etapas con tres
pasos en cada etapa:
▪ Construir el Modelo del Negocio
• Inicio del proyecto de modelado
• Definición de entidades
• Definición de relaciones
▪ Construir el Modelo de Diseño de Base de Datos
• Definición de PK
• Resolver relaciones N:M
• Definición de atributos No-llaves

Registrar Materiales de Origen
Número Nombre y Descripción Origen Comentarios
1 Orden de Compra – formato Formato en papel

enviado al departamento de
Compras
2 Libro de teléfonos Libro de papel (25 páginas)
3 Órganigrama Documento en papel Podría ser desfasado
Lista de Datos de Origen

Número Nombre Número de Propiedades de comentarios
material de origen Datos
111 Orden de 1 Caracter alfanumérico Nombre de
Compra de 14-dígitos documento
112 Número de 1, 22, 35 Número de 5-dígitos Única forma de
orden de rastrear la orden de
compra compra
113 Número del 1, 22, 15 Caracter alfanumérico Única identificación
vendedor de 10-dígitos del vendedor

▪ Para identificar entidades vaya a través de la lista de datos de
origen y encuentre todos los sustantivos. Algunas preguntas
para identificarlas son:
• ¿puede ser descrito?
• ¿tiene cualidades?
• ¿existen varias instancias de aquello?
• ¿puede una instancia ser separada o identificada a partir de otra
instancia?
• ¿se refiere o describe algo más? Para esta última pregunta, si la
respuesta es sí, entonces el item es probablemente un atributo en lugar
de una entidad.

Identificación de Entidades
Tipo de entidad Descripción
Persona Una entidad puede describir a una persona en el sistema tal como estudiante, empleado,
cliente, invitado, paciente, doctor, esposa, niño, o aún una mascota.
Lugar Una entidad puede describir cualquier localización geográfica en el sistema tal como aula,
edificio, región, zona de ventas, tienda, o país.
Evento Una entidad puede describir cualquier evento en el sistema tal como arribo, partida,
premiación, o una reunión.
Objeto Una entidad puede describir a un objeto real físico en el sistema tal como parte, inventario,
película, producto, herramienta, o una máquina.
Transacción Una entidad puede describir una transacción en los procesos de un sistema tal como
reservación, venta, inscripción, orden de compra, depósito, o un retiro.
Concepto Una entidad puede describir a un concepto en el sistema que no tenga una manifestación física
tal como una clase, semestre, procedimiento, cuenta, un segmento de tiempo, o una
asignación de trabajo.
Grupo Una entidad puede describir a un grupo de personas tal como departamento, equipo, division,
proveedor, o una empresa.

▪ Listado de todas las entidades potenciales en el Pool de
entidades
Pool de Entidades
Entidad # Nombre Definición Origen Comentarios
E1 Orden de compra Un documento autorizando la compra 2

de bienes
E2 Transportista Un vendedor quien proporciona 2, 3
servicios de envios
E4 Departamento La unidad de la organización a donde 2, 3, 5
los empleados son asignados
E5 Factura Un documento que requiere el pago 3
por servicios al cliente

▪ Una buena llave primaria o PK es:
• Identifica de forma única cada instancia
• Tiene un valor que no cambia durante la vida de la instancia que
representa
• Preferentemente es una llave simple
• Tiene un tipo de datos de número entero o corto, caracteres
alfanuméricos, de ancho fijo
• Preferiblemente, use una llave natural que se puede tomar desde el
sistema que se está modelando, pero si es necesario, una PK puede ser
definido como ProductID, StudentID, etc.

▪ Ejemplos de llave primaria o PK
ISBN es un código
internacional
Si la organización no Necesita un PK
tiene un ID único para los compuesto ya que el
miembros de su mismo número de cuarto
tripulación o Crew, o Room (e.g., Room
entonces uno debe ser 102) podría ocurrir en
creado. múltiples edificios.

▪ Migración de PK:
• Las PK´s deben migrar desde la entidad padre (el lado de Uno) a la
entidad hijo (el lado de Muchos)
• La PK completa debe migrar;
nunca divida una PK compuesta
• Sólo la PK migra a través de
una relación

▪ Relaciones redundantes: usualmente las relaciones directas
pueden ser eliminadas
porque son
redundantes.

▪ Resolviendo relaciones N:M

▪ El Modelo del Negocio
PurchaseOrder
Supplier SalesTransaction
InventoryProduct
fills
made by
has
has Customer
PurchaseOrderLine
is a
supplies SalesTransactionItem
Product sold in
SupplierPart uses
is for a
is in a
InventoryPart CreditCard
has fulfills
has
ProductCategory
Part ProductPart
is a

▪ Los Atributos No-llaves:
• Cada atributo debe tener un nombre único para ambos tanto atributos
como entidades
• Un atributo no puede tener el mismo nombre que una entidad o como
otro atributo.
• El nombre debe ser significativo y consistente en todo el modelo y su
definición es aplicable sólo a un nombre de atributo.

▪ Los Tipos de Datos y Dominios:
Tipo de Dato Dominio
• Cada atributo debe tener • El conjunto de valores que
un tipo de dato definido. un atributo puede asumir
• Los tipos de datos básicos • Un atributo puede o no
son: puede tener un dominio
▪ Number definido.
✓ Real • Dominio explícito
✓ Integer
▪ estados = {AL, FL, GA, NY, …}.
▪ Boolean
• Dominio definido
▪ Text
▪ GPA ≥ 0 AND GPA ≤ 4.0
▪ Date

▪ Un Diccionario de Datos: es un repositorio centralizado de
información sobre el modelo de datos
▪ Es parte de los metadatos (datos acerca de datos)
▪ Define los datos, tipo de datos, el dominio, el formato, y otra
información, según sea necesario.

Field Description Reason for Data Field Format Validation & Required Indexed Application found in
Name data Type Size other rules
Member_ PK. Unique sequential To track Text 6 Y Y Order System
id number members
FK in xxx tables
First The members first name Text 25 Y N Order System
Name
Last The members Last name Text 30 Y Y
Name
Phone# Members primary phone Text 10 (999)99 N N
number 9-9999
Join date The date that the member Used for Date 99/99/9 Default = N Y Marketing System
actually paid their initial promotions 9 today’s date
membership fee and data Validation
mining by rule: join date
marketing <=today’s date

https://www.youtube.com/watch?v=K6w0bZjl_Lw&t=71s
▪ Modelo de Diseño de una Base de Datos

2. La Base de Datos Relacional
▪ El modelo E/R es usualmente implementado con un
sistema de Base de Datos Relacional.
Términos del Modelo de Información Términos de base de Datos

Entidad Tabla
Atributo Campo
Instancia de entidad Registro

▪ El mapeo de un modelo E-R a una Base de datos:
La PK se convierte en un campo que

Cada atributo se convierte en
es obligatorio e indistinguible de
una columna o field(campo)
otros campos con valor excepcional
de la tabla
y ese valor debe ser único en la tabla
PassengerID FirstName LastName Children

52344-1 Bob McGuire
52345-1 Yuly Sanchez Carlos
52345-2 Carlos Sanchez
Cada fila de la tabla es un record(registro) o en el modelo llamado una instancia de la entidad

▪ SQL (Structured Query Language)
▪ SQL es un lenguaje declarativo para accesar datos en una base
de datos, tiene:
• DDL o Data Definition Language
• DML o Data Manipulation Language
▪ Centrado en el acrónimo CRUD lo cual es necesario para el
CRUD SQL
diseño de sistemas
Create Insert
empresariales.
Read Select
Update Update
Delete Delete

SQL Insert
INSERT INTO NombreTabla

([NombreAtributo1], [NombreAtributo2], ...)
VALUES (Valor1, Valor2, ...);
Todos los comandos SQL

finalizan con el delimitador
punto y coma “;”
INSERT INTO ShoreExcursion
(CodeExcursion, ExcursionName, Duration, PortCode)
VALUES (‘E502’, ‘Swim with Sharks’, 4, ‘BAH’);

▪ Suponga que la tabla ShoreExcursion tiene los datos mostrados:
Tabla: ShoreExcursion
Excursion ExcursionName Cost Duration Description Wheel Chair Activity Port
Code Accessible Level Code
E500 Swim with Dolphins $120 5 N 1 BAH
E501 Island Tour $45 3 A jeep tour of the island Y 1 KIN
E502 Swim with Sharks 4 BAH
E503 JetSki $60 2 Jet skiing in the bay Y 2 BAH
E504 Scuba Diving $100 5 Dive off wreck N 3 BAH
E610 Par-sailing $50 3 Fly 100 ft over beach N 2 VIR
E630 City Tour $50 5 A downtown jeep tour Y 1 MIA
E640 Snorkling $50 3 N 3 BAH
E650 Ghost Tour $25 3 Y 2 BAH

▪ En SQL insert, el orden de los nombres de los atributos deben
coincidir con el orden de los valores – no es necesario que
coincidan con el orden que esta escrito en la tabla.
▪ Ambos INSERT INTO ShoreExcursion
(ExcursionCode, ExcursionName, Duration, PortCode)
VALUES (‘E502’, ‘Swim with Sharks’, 4, ‘BAH’);
▪ e
INSERT INTO ShoreExcursion
(ExcursionName, Duration, PortCode, ExcursionCode)
VALUES (‘Swim with Sharks’, 4, ‘BAH’, ‘E502’);
▪ Crean el mismo registro.

SQL Select
▪ Lee los datos desde una base de datos
SELECT [DISTINCT] NombreAtributo1, NombreAtributo2, ...
FROM NombreTabla(s)
[WHERE] Predicado
[ORDER BY] Atributo ASC o DESC;

Tabla: ShoreExcursion
Excursion ExcursionName Cost Duration Description Wheel Chair Activity Port
Code Accessible Level Code
E500 Swim with Dolphins $120 5 N 1 BAH
E501 Island Tour $45 3 A jeep tour of the island Y 1 KIN
E502 Swim with Sharks 4 BAH
E503 JetSki $60 2 Jet skiing in the bay Y 2 BAH
E504 Scuba Diving $100 5 Dive off wreck N 3 BAH
E610 Par-sailing $50 3 Fly 100 ft over beach N 2 VIR
E630 City Tour $50 5 A downtown jeep tour Y 1 MIA
E640 Snorkling $50 3 N 3 BAH
E650 Ghost Tour $25 3 Y 2 BAH
SELECT ExcursionName, Cost, Duration

FROM ShoreExcursion
WHERE Duration <= 3 AND Cost <= 50 AND PortCode = ‘BAH’;
ExcursionName Cost Duration
Snorkling $50 3
Ghost Tour $25 3
SQL Select usado para Juntar Tablas
▪ Usted junta tablas (usualmente) de acuerdo a la relación entre
la llave primaria (su valor) y llave foránea (igual valor)
SELECT Cruise.DepartureDate
FROM Cruise, Ship
WHERE Ship.ShipID = Cruise.ShipID AND Ship.ShipName = “SeaScape”;
• La clausula WHERE define la unión entre dos tablas.
• Este query obtiene todas las fechas de salida del crucero hechas por el barco SeaScape
• Necesitamos unir las tablas ya que los datos residen en dos tablas diferentes.
• Note el uso de la “notación punto” para los nombres de los atributos cuando las
ocurrencias estan en dos tablas

SQL Update
UPDATE TableName
SET AttributeName = Expression [,attribute name = Expression, ...]
[WHERE Predicate];
UPDATE ShoreExcursion
SET Cost = Cost + 10
WHERE PortCode = ‘BAH’;

SQL Delete
DELETE
FROM tablename
[WHERE predicate ]
DELETE
FROM ShoreExcursion
WHERE PortCode = ‘BAH’;

Reglas de Base de Datos
▪ La regla de integridad de la entidad dice que todas los valores de entradas de
PK´s son únicas, y que ninguna parte de la PK puede ser nula.
▪ La integridad de la entidad garantiza que cada instancia de una entidad puede
ser únicamente identificada y asegura que los valores de las FK´s puedan
referenciar los valores de la PK´s apropiadamente.
▪ La regla de integridad referencial dice que los valores de la FK´s son

requeridas para que coincida a aquellas de la PK o ser completamente nula.
▪ La integridad referencial asegura que los datos en la entidad hijo puedan ser
coincidentes con los datos en la entidad padre.

Integridad Referencial
Tabla PORT (Puerto)
• Los valores para el campo PortCode en la
tabla EXCURSION debe coincidir con los PortCode PortName
valores en la table PORT o ser nulo. BAH Nassau, Bahamas
MIA Miami
Tabla EXCURSION
DEBE
coincidir o
ser NULO
FLL
? Fort Lauderdale
Excursion ExcursionName Cost PortCode Duration

Code • Las excursiones E500 y
E500 Swim with Dolphins $120 BAH 5 E630 satisfacen la regla de
E501 Island Tour $45 KIN 3 integridad referencial
porque sus valores de
E503 JetSki $60 2
PortCode coinciden con los
E630 City Tour $50 MIA 5 valores en la tabla PORT
• La excursión E501 viola la regla de integridad referencial porque el valor de PortCode es KIN y ese
valor no coincide con ningún registro en la tabla PORT
• La excursión E503 satisface la regla de integridad referencial porque su valor en PortCode es Null

3. Normalización
▪ Es el proceso de reconocer propiedades indeseables
(anomalías) en el modelo de Información y convertir el modelo
en una forma deseable y de mayor velocidad en la red.
▪ Remover redundancias
▪ Asegurar que las dependencias de datos tengan sentido
▪ Las transiciones del modelo a través de una serie de etapas
llamadas formas normales: first normal form (1NF), second
normal form (2NF), third normal form (3NF).
▪ Para estar en 2NF, el modelo debe estar primero en 1NF
▪ La Normalización es hecha para cada entidad en el modelo.
Anomalías
▪ Las anomalías son inconvenientes o situaciones propensas a
errores que surgen al momento de procesar las tablas
▪ Existen 3 tipos:
Tipo de Anomalía Descripción

Insert Un registro no puede ser insertado en una tabla al menos que la
(inserción) información esté insertada primero en otra tabla de datos o
datos fantasmas sean creados.
Update Un registro no se puede actualizar sin cambiar los datos en
(actualización) muchos lugares diferentes. Esto puede ser muy difícil de
manejar.
Delete Un registro no se puede eliminar sin eliminar un registro de una
(eliminación) entidad relacionada

Ejemplos de Anomalías
▪ Si queremos actualizar la ciudad (city) donde reside Bob Smith,
necesitamos hacerlo en varios lugares – anomalía de
actualización.
OrderNumber CustomerID LastName FirstName City TotalAmount
123 A1 Smith Bob Monterey $127.50
133 A5 Belevaqua Frank Fort Pierce $50.00
▪ No podemos crear un cliente al menos que creemos un número

de orden (OrderNumber) – anomalía de inserción.

▪ Si queremos eliminar la orden 133 perderemos también toda la
información acerca de nuestro cliente Frank – anomalía de
eliminación.
OrderNumber CustomerID LastName FirstName City TotalAmount
133 A5 Belevaqua Frank Fort Pierce $50.00

Formas de Normalización
Normal Level Description
First Normal Form No grupos repetidos; cada atributo tiene un simple y único
(1NF) valor.
Second Normal No dependencias parciales; todos los atributos no-llaves
Form (2NF) dependen enteramente de la PK.
Third Normal No dependencias transitivas; i.e., un atributo no-llave no
Form (3NF) puede depender de otro atributo no-llave.
▪ Resultados de la Normalización:
Cada tabla representa un simple asunto o tema.
Ningún elemento de los datos será almacenado innecesariamente en
más de una tabla.
Todos los atributos en una tabla seran dependientes de la PK.

Necesidad de Normalización

© Elmer González Herrera, Doctor en Ingeniería Industrial
curso: Ingeniería de la Información Empresarial, VI ciclo 2018

Resultado Final
• PROJECT (PROJ_NUM, PROJ_NAME)
• ASSIGN (PROJ_NUM, EMP_NUM, ASSIGN_HOURS)
• EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)
• JOB (JOB_CLASS, CHG_HOUR)

Diccionario de Datos
▪ El modelo de Información se sustenta en un conjunto de
elementos de datos de mutuo acuerdo de nombres y
definiciones claramente definidas.
▪ Un diccionario de datos es un repositorio centralizado de
información acerca de datos tal como tipos de datos,
significados, relaciones a otros datos, origen, usos, y formato de
cada atributo.
▪ Es parte de los metadatos (datos acerca de datos)

Field Description Reason for Data Field Format Validation & Required Indexed Application found in
Name data Type Size other rules
Member_ PK. Unique sequential To track Text 6 Y Y Order System
id number members
FK in xxx tables
First The members first name Text 25 Y N Order System
Name
Last The members Last name Text 30 Y Y
Name
Phone# Members primary phone Text 10 (999)99 N N
number 9 - 9999
Join date The date that the member Used for Date 99/99/9 Default = N Y Marketing System
actually paid their initial promotions 9 today’s date
membership fee and data Validation
mining by rule: join date
marketing <=today’s date

▪ El resultado final del modelado de la información es un modelo
de definición de base de datos que incluya.
• El modelo entidad-relación final, llamado un Modelo de Definición de
Base de Datos
• La Crónica (log: “historial”) de Material de Origen
• La Lista de material de Origen.
• El pool de entidades
• El pool de atributos
• El Diccionario de Datos.

4. Resumen
▪ El resultado final del diseño de la información es un modelo de
definición de base de datos que incluye.
• El modelo entidad-relación final, llamado un Modelo de Definición de
Base de Datos
• La Crónica (log: “historial”) de Material de Origen
• La Lista de material de Origen.
• El pool de entidades
• El pool de atributos
• El Diccionario de Datos.

El modelo Entidad/Relación proporciona una perspectiva
de la información en la arquitectura empresarial.
El Modelo de Definición de la Base de Datos, describe el

contenido de la Información del Sistema

La Información del Sistema: objetos y relaciones entre
ellos, el diccionario de datos definen todos los atributos,
sus tipos de datos, y dominios.
Juntos estos documentos son suficientes para construir

una BASE DE DATOS


20191103201129895361 (1)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

20191103201129895361 (1)

Caricato da

Copyright:

Formati disponibili

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

semanas 14-15: NOV 18 – 29

NRC: 1919, martes 6:00 pm → 9:35 pm (Práctica en el aula G409)

por: ELMER GONZALEZ HERRERA

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

1 Orden de Compra – formato Formato en papel

3 Órganigrama Documento en papel Podría ser desfasado

Lista de Datos de Origen

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

E1 Orden de compra Un documento autorizando la compra 2

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

▪ Modelo de Diseño de una Base de Datos

Términos del Modelo de Información Términos de base de Datos

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

La PK se convierte en un campo que

PassengerID FirstName LastName Children

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INSERT INTO NombreTabla

Todos los comandos SQL

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

▪ Crean el mismo registro.

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

SELECT ExcursionName, Cost, Duration

ExcursionName Cost Duration

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

▪ La regla de integridad referencial dice que los valores de la FK´s son

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

Excursion ExcursionName Cost PortCode Duration

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

Tipo de Anomalía Descripción

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

123 A1 Smith Bob Monterey $127.50

125 A1 Smith Bob Monterey $250.25

133 A5 Belevaqua Frank Fort Pierce $50.00

▪ No podemos crear un cliente al menos que creemos un número

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

OrderNumber CustomerID LastName FirstName City TotalAmount

123 A1 Smith Bob Monterey $127.50

125 A1 Smith Bob Monterey $250.25

133 A5 Belevaqua Frank Fort Pierce $50.00

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe

INGENIERIA DE INFORMACIÓN EMPRESARIAL e-mail: egonzalezh@upao.edu.pe