BASE DE DATOS

FECHA INCIO 3 De Abril De 2020 FECHA ENTREGA 17 De Abril De 2020 DURACION 3 Horas Presenciales
6 Horas Autónomas
ASIGNATURA Base De Datos ACTIVIDAD Modelo Físico – Manejo de tablas DOCENTE
Marcela Silva Torres

OBJETIVO GENERAL
OBJETIVOS ESPECIFICOS
MEDIO ENTREGA
CRITERIOS DE EVALUACIÓN
BIBLIOGRAFIA E INFOGRAFIA
Identificar e implementar los criterios necesarios para diseñar una base de datos que pueda ser construida en cualquier
SGBD - gestor de bases de datos -, aplicando las normas y principios del diseño e implementación de Bases de Datos
relacionales.
 Realizar procesos de abstracción de datos, apoyado en el análisis de problemas específicos de sistemas de
información
 Diseñar un esquema de base de datos, aplicando técnicas de modelamiento de datos, integridad referencial y
procesos de normalización
 Implementar diseños de las bases de datos relacionales, a través del uso de un gestor de bases de datos,
mediante el uso del lenguaje de definición y manipulación de datos.
Se entregarán durante la práctica el proceso realizado en clase y al final de cada corte un informe IEEE con pantallazos del
proceso como evidencia de aprendizaje. Todo de manera digital.
 Demostrar los conocimientos adquiridos sobre la práctica realizada, proponiendo por la formación de profesionales
en Tecnología de Sistemas con carácter, criterio y capacidad de actuación independiente y toma de decisiones, con
responsabilidad y ética de acuerdo con los conocimientos adquiridos propios del área de formación en los Sistemas de
Información y la Aplicación de Tecnologías de Información.
 Participar en la apropiación del conocimiento a través de su vinculación mediante actividades teórico-prácticas tales
como talleres, investigaciones, visita de campo, entre otros, que lo impulsen al logro de los propósitos de formación
planteados, mediante el descubrimiento, construcción, reconstrucción y el desglose de problemas reales enfocados a
buscar soluciones de tipo sistémico.
 Sustentar coherentemente el proceso realizado en la apropiación del conocimiento a través de su vinculación
mediante actividades teórico-prácticas tales como talleres, investigaciones, visita de campo, entre otros, que lo
impulsen al logro de los propósitos de formación planteados, mediante el descubrimiento, construcción,
reconstrucción y el desglose de problemas reales enfocados a buscar soluciones de tipo sistémico.
1. Date, CJ (2005). Introducción a los Sistemas de Base de datos. Séptima Edición.
Editorial Prentice Hall
2. • Groff, James & Weinberg, Paul (1998). Guía LAN TIMES de SQL. Madrid, Editorial Mc Graw Hill.
3. • Shakuntala Atre (1988). Técnicas de Bases de datos. Estructuración en diseño y Administración.
México, Editorial Trillas
4. • DuBois, Paul. (2001). Edición especial MySQL. Madrid, Editorial Prentice Hall.
5. • Ramalho Microsoft SQL SERVER. Manual de referencia. 2006
Abbey, Michael y Corey Michael J. Oracle 9i. Edición Oracle Press. 2006

INTRODUCCIÓN

El modelo de datos físicos representa cómo se construirá el modelo en la base de datos.

Un modelo de base de datos física muestra todas las estructuras de tabla, incluidos el nombre de columna, el tipo de
datos de columna, las restricciones de columna, la clave principal, la clave externa y las relaciones entre las tablas.

Facultad de Ingeniería
UNIMINUTO Centro Regional Soacha
Sede Académica: Transversal 5 No. 5 G – 95 Sur. Tel 2916520 ext 3318
Las características de un modelo de datos físicos incluyen:
 Especificación de todas las tablas y columnas.
 Las claves externas se usan para identificar relaciones entre tablas.
 La des normalización puede ocurrir según los requisitos del usuario.

Las consideraciones físicas pueden hacer que el modelo de datos físicos sea bastante diferente del modelo de datos
lógicos. El modelo de datos físicos será diferente para diferentes Sistemas de Gestión de Base de datos. Por ejemplo, el
tipo de datos para una columna puede ser diferente entre MySQL y SQL Server.

Los pasos básicos para el diseño del modelo de datos físicos son los siguientes:
 Convertir entidades en tablas.
 Convertir relaciones en claves externas.
 Convertir atributos en columnas.
 Modificar el modelo de datos físicos en función de las restricciones / requisitos físicos.

GENERALIDADES
Cuando ya tenemos claro cuál es el problema a resolver y queremos diagramar la solución, optamos por usar al
menos el diagrama de casos de uso y/o el diagrama de clases. Con el primero para obtener más beneficios en
cuestión de calidad y control del proyecto. Y el segundo para desarrollar sistemas más ORIENTADOS A
OBJETOS.

¿Uno o Dos Artefactos?

Hay quien desarrollaría el diagrama de clases desde una sola perspectiva, modelando las clases de software a
implementar. Es decir, realizando directamente el diseño de la aplicación. Mi recomendación al respecto es que si
quieren sacarle el máximo provecho al diagrama de clases es conveniente desarrollarlo en dos ciclos. Uno de análisis y
otro de diseño, lo cual implica que en realidad están desarrollando dos artefactos en el proceso en lugar de uno; ambos
usando el diagrama de clases como base.

En el primero de estos ciclos, el de análisis, se desarrolla lo que podemos llamar diagrama preliminar de clases, modelo
del dominio o modelo conceptual. No importa el nombre, lo que importa es lograr el objetivo de comprender el dominio
(contexto del problema); con el beneficio indirecto de estar estableciendo las posibles clases del sistema. Ya en el ciclo
de diseño este diagrama preliminar será usado como una base a refinar para determinar las clases definitivas a
implementar en el sistema orientado a objetos.

La Comprensión del Problema

El modelo conceptual. Su relevancia radica en que si no comprendemos el dominio del problema y las reglas de negocio
habrá pocas esperanzas de sugerir y desarrollarle un buen sistema a nuestro cliente. Y entre más complejas sean las
reglas de negocio, más fácilmente tenderemos al fracaso si no logramos esta comprensión.

Imagina que te solicitaron desarrollar un sistema para vender pólizas de seguros de vida. Pero, quizás nunca en tu vida
has comprado un seguro, por lo que no tienes ni idea de los conceptos de dicho. No sabes que las pólizas de estos
seguros sirven para asegurar a un cliente por un monto, ni que el plan cubierto por esa póliza es para un tipo de seguro
de vida que puede elegir el cliente entre los diferentes planes que aplican de acuerdo a sus características, ni que el

Facultad de Ingeniería
UNIMINUTO Centro Regional Soacha
Sede Académica: Transversal 5 No. 5 G – 95 Sur. Tel 2916520 ext 3316, 3317,3319
cliente puede seleccionar también un tipo de pagos para pagar su póliza a diferentes plazos y montos, ni sabes tampoco
que la póliza puede tener desde uno hasta un máximo de 10 beneficiarios.

Bueno, pues si yo fuera el cliente y tú no lograras comprender los puntos anteriores, ten por seguro que me buscaría a
alguien más para que me lo desarrollara. Y este es un ejemplo simple, pues las reglas de negocio de cualquier sistema,
sabemos que pueden ser mucho más complejas. No por nada alguien dijo: “empiezo a pensar que es más fácil enseñarle
a mi gente de negocios cómo desarrollar sistemas que a la gente de sistemas el negocio”.

Enlistar textualmente estas reglas en un documento puede ser útil, pero cuando tienes un documento de varias hojas
para explicar el dominio es muy fácil que la gente comience a sentirse agobiada por tanta información. En cambio, si usas
un modelo conceptual para expresarlas será mucho más fácil documentarlas, analizarlas y comprenderlas. Con la
ventaja, como ya comenté, que estarás estableciendo las bases para construir una aplicación orientada a objetos.

Los elementos principales a mostrar en el modelo conceptual son:

 Conceptos. Elemento lógico o físico que ayuda a entender el problema, es parte del lenguaje utilizado por el
cliente y generalmente se nombra como sustantivo. Se representan con el símbolo de una clase. Ejemplo:
Cliente, Póliza y Domicilio.
 Atributos. Información que caracteriza al concepto en el mundo real. Se muestra en el segundo compartimiento
de las clases. Ejemplo: Nombre, apellidos y edad del cliente.
 Asociaciones. Relaciones lógicas o físicas que existen en el mundo real entre dos conceptos. Si puedes armar
una frase con dos conceptos significa que la puedes representar mediante una relación de asociación entre esos
dos conceptos. Puedes colocarle el verbo que usas para relacionar los conceptos en la frase, indicándolo sobre
la asociación con una punta de una flecha para indicar la dirección en que se debe leer la frase. Ejemplo: La
Póliza cubre-a un cliente asegurado, el cliente vive-en un domicilio.
 Rol. El rol también puede aclarar la relación entre dos conceptos, indica el rol que juega un concepto con
respecto a otro en una relación de asociación. Ejemplo: PlanesAplicables al cliente.

Facultad de Ingeniería
UNIMINUTO Centro Regional Soacha
Sede Académica: Transversal 5 No. 5 G – 95 Sur. Tel 2916520 ext 3316, 3317,3319
  Multiplicidad. El número de instancias de un concepto relacionados con el otro concepto. Ejemplo: Una póliza
tiene una lista de uno a diez beneficiarios.
 Generalización. En lugar de poner una asociación para armar la frase “es-un-tipo-de” podemos poner una
generalización. Aunque esto podría crear confusión en los lectores no técnicos, por lo que hay que asegurarse
que el lector del modelo entienda perfectamente el significado de la notación. Ejemplo: El Plan Oro es un tipo de
plan de seguro de vida, al igual que el plan tradicional.
 Agregación y composición. Indican una relación donde uno de los conceptos es el contenedor del otro.
Ejemplo: la póliza contiene una ListaBeneficiarios.

Estos son los elementos básicos a utilizar para aclarar el dominio de un problema. Aunque hay quien gusta de
indicar también algunas operaciones que reflejan el comportamiento o las acciones que se pueden realizar
asociadas a un concepto. Ejemplo: A un cliente se le pueden cargarPlanesAplicables().

TALLER

1. Ingrese al siguiente link y vea el video sobre modelos conceptuales:

https://youtu.be/m49huH2NHJ8

2. Elabore el diagrama Entidad Relación y la tabla correspondiente de los siguientes problemas:

Se desea almacenar la información de una compañía aérea en una base de datos relacional. La compañía
aérea tiene tres recursos principales: aviones, pilotos y miembros de tripulación. De cada piloto se desea
conocer su código, nombre y horas de vuelo. De los miembros de tripulación sólo mantendremos su código y
nombre. Todos ellos (pilotos y miembros) tienen una base a la que regresan después de los vuelos de una
jornada. Un vuelo que va desde un origen a un destino y a una hora determinada, tiene un número de vuelo
(por ejemplo, el vuelo de Palma a Alicante de las 13:50 es el vuelo IB-8830). De cada vuelo que se va a
realizar durante los próximos tres meses, así como de los vuelos que ya se han realizado, se desea saber el
avión en que se va a hacer o en el que se ha hecho, el piloto y cada uno de los miembros de la tripulación.
Cada avión tiene un código, es de un tipo (por ejemplo, BOEING-747) y tiene una base donde es sometido a
las revisiones periódicas de mantenimiento.

El servicio de estudiantes de la universidad proporciona información sobre las asignaturas de cada titulación e
información sobre los profesores, mediante los tipos de informe que se muestran más adelante. Para ello,
posee un fichero de asignaturas y un fichero de profesores, con los correspondientes programas que se
encargan de gestionarlos y que generan dichos informes. Dados los problemas de inconsistencia de datos
que el sistema de ficheros conlleva, se desea diseñar una base de datos relacional que lo sustituya. Algunas
aclaraciones que el servicio de estudiantes nos ha hecho son las siguientes: en cada departamento hay
varias áreas de conocimiento, cada una de las cuales imparte una serie de asignaturas distintas en una o
varias titulaciones. Cada profesor pertenece a una única área de conocimiento de un departamento e imparte
clases en una o varias asignaturas de esa área.

El taller resuelto debe ser entregado hasta el 15 de Abril al correo de la docente.

Facultad de Ingeniería
UNIMINUTO Centro Regional Soacha
Sede Académica: Transversal 5 No. 5 G – 95 Sur. Tel 2916520 ext 3316, 3317,3319