PRÁCTICA 01 MODELAMIENTO DE BD

LAURA XIMENA TINJACA RODRIGUEZ 20151025104

MARIO DAVID RAMIREZ ALDANA 20141025035

INFORME DE INGENIERÍA

PROFESOR

FABIAN CAMILO CASTELLANOS PINTO

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD DE INGENIERIA

INGENIERIA CATASTRAL Y GEODESIA

BASES DE DATOS ESPACIALES

2019 - I
 OBJETIVO

Modelar una base de datos que permita relacionar los datos de los clientes de una
compañía de telefonía celular, con cada uno de los equipos que adquirió en la misma, y si
es el caso emparejar esta información con el paquete de servicios del cual hace uso, de
manera tal que permita a la compañía generar una factura por cada uno de los equipos,
que tenga asignado un plan o paquete de servicios dentro de esta.

Adicionalmente se busca relacionar la información del cliente, emparejada con la del

equipo que adquirió dentro de la compañía, para asignar un código de registro único o
IMEI que será asignado por la Comisión de Regulación de Comunicaciones (CRC). Con
el fin de brindar al cliente una garantía sobre su equipo en caso de robo o pérdida.

MODELO FÍSICO

Nombre Descripción
Usuario Es el cliente de la empresa el cual puede
adquirir servicios de la empresa
Plan de Usuario Servicio de la empresa en este caso contiene
simcard y equipo celular
Plan Servicio de la empresa de telefonía el cual
puede tener datos, SMS o minutos y depende
si el usuario lo desea adquirir
Factura Documento con información de la empresa e
información de deudas del usuario con la
empresa
Registro Comisión de Regulación de
Comunicaciones (CRC) donde se registra
el IMEI del celular para proteger a los
usuarios
Equipo Es los modelos de celulares que ofrece la
empresa
Tabla 1: Diccionario de entidades
 Nombre Pertenece a Estructura Opcional Descripción

Tipo de Longitud
dato

numero_factu Factura Numeric 10 no Numero de

ra factura que
tiene el
usuario con la
empresa

Id_usuario Usuario Numeric 10 no Cedula del

usuario

Nombre Usuario Char 10 no Nombre de

usuario

Apellido Usuario Char 10 no Apellido del

usuario

Direccion Usuario Char 15 no Direccion de

residencia de
usuario

Id_plan Plan Integer 1 no Numero de

plan del
usuario por
ejemplo 1

minutos plan Char 25 si Corresponde a

el número de
minutos que
contiene el
plan

SMS plan Char 25 si Corresponde a

la cantidad de
mensajes que
 contiene el
plan

datos plan Char 25 si Corresponde a

la cantidad de
datos que
tiene el plan

Id_simcard Plan de usuario Numeric 10 No Corresponde

al número de
simcard
entregada por
la empresa al
usuario

Id_equipo equipo Integer 2 no Numero

identificador
de modelo del
equipo

Nombre_equi Equipo Char 20 no Nombre del

po modelo del
equipo

Numero_regis Registro Numeric 15 no Corresponde

tro al registro que
se hace ante
la CRC (IMEI)

Tabla 2: Diccionario de atributos

MODELO ENTIDAD RELACION

MODELO CONCEPTUAL
VERIFICACION DE LAS FORMAS NORMALES

MULTIPLES VALORES

USUARIO

Id_usario: esta es la llave primaria, es un código único que se le asigna al usuario por lo
tanto no es posible que tenga más de un valor, tampoco cambia en el tiempo.

Nombre: Este atributo tampoco cambia en el tiempo y no hay manera de que tenga más
de un valor, aunque el usuario puede tener mas de un nombre estos no serán separados
por punto y coma ya que se considera que independientemente del número de nombres
estos hacen parte del nombre como tal.

Apellido: Este atributo tampoco cambia en el tiempo y no hay manera de que tenga más
de un valor, aunque el usuario puede tener dos apellidos, estos no serán separados por
punto y coma ya que se considera que independientemente del número de apellidos estos
hacen parte del apellido como tal.

Dirección: Este atributo si puede cambiar en el tiempo por lo tanto es posible que exista
multiplicidad en los valores

Por lo tanto es necesario crear una nueva entidad donde el id_usuario sea la llave foránea
y tenga como llave primaria un atributo nombrado id_direccionus. De manera tal que
podamos almacenar más de una dirección para un mismo usuario.

PLAN

Id_plan: es la llave primaria de la entidad plan por lo tanto no hay manera de que haya
multiplicidad en los valores.

SMS: este atributo solo puede recibir un valor ya que en un plan solo es posible tener un
paquete de mensajes, si puede ser variable en el tiempo pero por su naturaleza,
requeriría que remplazáramos completamente la información del atributo.

Lo mismo ocurre para los atributos Minutos y datos ya que son de la misma naturaleza.

PLAN DE USUARIO:

Id_simcard: es la llave primaria por lo tanto es única y no varía.

EQUIPO:

Id_equipo: es la llave primaria.

Nombre_equipo: el nombre del equipo es único para cada equipo.

Numero_registro: el numero de registro o IMEI es único para cada equipo.

REDUNDANCIA

Básicamente el análisis es el mismo para el caso de multiplicidad, en valores para este

modelo de base de datos en particular.

Sin embargo, existe la posibilidad y de hecho es muy probable que exista un usuario con
diferentes equipos y por lo tanto diferentes planes pero este problema se soluciona con el
atributo de la entidad equipo Numero_registro o IMEI, que es único para cada equipo y
cada equipo solo puede tener un plan.

ACTUALIZACION

Teniendo en cuenta que el análisis hecho para la forma normal de multiplicidad en

valores, y que como resultado tuvimos que solo puede presentarse en el atributo dirección
de la entidad usuario la solución a este problema quedo resuelta anterior mente.

INTEGRIDAD DE LA INFORMACION

Ninguna de las llaves primarias admite valores nulos.

CONCLUSIONES

El manejo de información de una base de datos se hace sustancialmente más cómodo

cuando la información que se utiliza corresponde en gran medida a llaves primarias. En la
vida real esto no sucede frecuentemente ya que en la mayoría de bases de datos, hay
mucha información que aunque es variable y no es propia de cada entidad, es muy
importante. Por lo cual se hace necesario saber descomponer la información y
relacionarla de manera adecuada, esto muchas veces implica la creación de nuevas
entidades. De hecho la información que es susceptible de ser analizada en la mayoría de
los casos es altamente variable. Razón por la cual de manera personal consideramos que
la importancia de una base de datos funcional radica en la eficacia y orden en que se
hacen las relaciones entre las entidades, para que estas se acomoden a la situación que
desea optimizar o solucionar.