Taller Base de Datos

Base de datos para la administración de un taller mecánico.
ACTIVIDAD EN CONTEXTO
Segunda entrega
Base de datos para la administración de un taller

mecánico.
Presentado por:
Estudiantes
Docente
Luis Ernesto Leyva Camargo
06 de septiembre de 2020
i
RESUMEN
BASE DE DATOS PARA LA ADMINISTRACIÓN DE UN TALLER

MECÁNICO.
Este documento corresponde a la elaboración de una Base de Datos

para la administración de un taller mecánico, el proyecto ha consistido
en desarrollar una Base de Datos para un cliente ficticio cuyas
necesidades están descritas en el enunciado de la práctica presentado
por el docente de la asignatura.
Esta Base de Datos debe proporcionar persistencia a una aplicación cuyo

desarrollo debe ofrecer los procedimientos y funciones almacenados
necesarios para que la aplicación que interactúe con la Base de Datos de
manera eficiente. El documento describe las diferentes fases de
desarrollo del proyecto: Planificación, Análisis y Diseño.
Palabras claves: Base de Datos, inteligencia de negocios, relacional,

eficiencia.
ii
ABSTRACT
DATABASE FOR THE ADMINISTRATION OF A MECHANICAL

WORKSHOP.
This document corresponds to the elaboration of a Database for the

administration of a mechanical workshop, the project has consisted of
developing a Database for a fictitious client whose needs are described
in the statement of the practice presented by the teacher of the subject.
This Database must provide persistence to an application whose

development must offer the stored procedures and functions necessary
for the application to interact with the Database efficiently. The
document describes the different phases of project development:
Planning, Analysis and Design.
Keywords: Database, business intelligence, relational, efficiency.
iii
INDICE
JUSTIFICACIÓN DE LA INVESTIGACIÓN 8
PLANTEAMIENTO DEL PROBLEMA Y PREGUNTAS DE INVESTIGACIÓN 10
OBJETIVOS 11
Objetivo General......................................................................................................................................11
Objetivos específicos.............................................................................................................................11
DISEÑO CONCEPTUAL 12
1. Identificación de entidades, atributos y relaciones..............................................12
2. Construcción del modelo conceptual..............................................................................13
3. Proceso de normalización.....................................................................................................14
3.1. Base de datos no normalizada 14
3.2. Primera Forma Normal (1FN) 16
3.3. Segunda Forma Normal (2FN) 19
3.4. Tercera Forma Normal (3FN) 22
4. Construcción del modelo lógico.........................................................................................26
4.1. Esquema relacional 27
5. Diseño Físico.................................................................................................................................29
5.1. Diccionario de datos 30
5.2. Reglas de negocio 33
5.2.1. Productividad en las transacciones 35
5.2.2. Tiempo de respuesta 36
5.2.3. Espacio en Disco 37
5.2.4. Tipos de archivos 37
5.2.5. Memoria principal 39
5.2.6. Criterios para selección de SGBD 40
6. SQL......................................................................................................................................................41
6.1. Creación de la base de datos 41
6.2. Creación de tablas 41
6.3. Creación de funciones, procedimientos, cursores, triggers 44
6.4. Consultas pertinentes según el caso 46
7. Informe de pruebas..................................................................................................................47
8. Aplicación de ACID al caso...................................................................................................47
9. Análisis de datos.........................................................................................................................47
iv
10. Implementación física.............................................................................................................47

10.1. Hardware 47
10.1.1. Modelo de servidor recomendado 47
10.1.2. Almacenamiento 48
Usualmente se encuentran en el mercado tres tipos de almacenamiento de bases de
datos: Unidades SATA, unidades SSD y NVMe, en orden de más lento a más rápido y
de menos a más caro. 48
10.2. Conectividad 48
10.3. Seguridad 48
11. Conclusiones.................................................................................................................................49
BIBLIOGRAFÍA BÁSICA 49
v
ÍNDICE DE TABLAS
Tabla 1 Datos no normalizados.....................................................15

Tabla 2 Primera Forma Normal......................................................17
Tabla 3 Segunda Forma Normal.....................................................20
Tabla 4 Tercera Forma Normal......................................................23
Tabla 5 Diccionario de datos.........................................................30
vi
ÍNDICE DE FIGURAS
Figura 1 (para actualizar la numeración, botón derecho, actualizar

campos) Diseño Conceptual: Modelo Entidad Relación, notación Chen. 13
vii
JUSTIFICACIÓN DE LA INVESTIGACIÓN
El mundo de hoy se está globalizando y cada vez se hace más necesario

que todas las partes que conforman esta sociedad se actualicen y estén
a la vanguardia con las demás, por tal motivo las pequeñas empresas y
en el mundo buscan sistematizarse para así estar a la altura de las
grandes empresas y poder progresar.
Si un Sistema de Gestión de Base de Datos se gestiona adecuadamente,

la empresa obtendrá diferentes ventajas. Aumentará su eficacia, habrá
trabajos que se realicen con mayor rapidez y agilidad debido a la
simplificación de los mismos, podremos mejorar la seguridad de los
datos que almacenamos, y con todos estos factores, maximizaremos los
tiempos y, por tanto, se producirá una mejora en la productividad.
De lo anterior surge la oferta que hace la tecnología para la solución de

aquellos problemas de organización que no permite que una empresa se
supere. Muchas de las labores realizadas hoy en día pueden ser o son
más productivas cuando se utiliza la tecnología o un software, sea cual
sea el ámbito en que se esté trabajando.
El cliente es un Taller de Mecánica de vehículos. El cliente quiere que se

registre la actividad de los clientes, el ingreso de los vehículos, el
personal que trabaja al interior del taller y los insumos necesarios para
desarrollar las actividades de mantenimiento y reparación y que a su
vez se puedan generar las facturas correspondientes.
Estas funcionalidades aportarán un valor añadido a la empresa objeto de

estudio, ya que con una base de datos formulada correctamente,
8
conseguiremos que la información y el conocimiento sean los mayores

activos de la entidad, lograremos obtener el máximo rendimiento a las
competencias de nuestros colaboradores, así como averiguar datos de
nuestros clientes potenciales. Por último, puesto que la información es
poder, cuantos más datos tengamos, mayor será la competitividad de la
compañía.
El objetivo es brindar una solución eficiente que pueda garantizar la

gestión de la información al interior del taller y cumplir los
requerimientos presentados para el desarrollo de la actividad
académica. El proyecto considerado en este documento corresponde al
desarrollo de la Base de Datos mencionada.
9
PLANTEAMIENTO DEL PROBLEMA Y PREGUNTAS DE

INVESTIGACIÓN
Como lo plantea el ejercicio académico en el taller de mecánica a diario

se maneja un gran flujo de información del cual se derivan las diferentes
labores, dicha información no es debidamente organizada por lo cual se
pierde veracidad, aumentan los tiempos de respuesta y se extravían
documentos lo cual conlleva a la perdida de efectividad en los procesos
y como última consecuencia la perdida de dinero.
La falta de un sistema de información eficiente hace que los procesos se

vuelvan más lentos, dispendiosos y se tenga que recurrir a métodos
manuales, como por ejemplo listados hechos a mano o en el mejor de
los casos recurren al uso de programas que no son los más adecuados
para el manejo de información vital al interior del taller.
Es por eso que nos planteamos el siguiente cuestionamiento ¿se puede

diseñar una base de datos relacional para garantizar flujos de
información eficientes al interior del taller de mecánica?
10
OBJETIVOS
Objetivo General
Diseñar un modelo de Base de Datos para la administración eficiente de

la información de clientes y personal operativo del taller de mecánica.
Objetivos específicos
1. Estructurar un modelo de Base de Datos de los clientes, los

vehículos, los empleados del taller de mecánica que permita
realizar una consulta organizada.
2. Diseñar un modelo de base de Datos que permita establecer a
los empleados la cantidad de repuestos y horas laboradas
durante un servicio de reparación o mantenimiento.
3. Crear un diagrama relacional y de identidad relación de la Base
de Datos.
11
DISEÑO CONCEPTUAL
1. Identificación de entidades, atributos y relaciones
El primer paso en el desarrollo de la Base de Datos para la

administración del Taller de Mecánica es la identificación de las
entidades, atributos y relaciones en este caso las entidades
corresponden a: Cliente, Vehículo, Servicio, Empleado, Repuesto y
Factura.
1. Se registra tanto el cliente como el vehículo que trae al taller para

su reparación. Este registro recoge el número de documento,
Nombre y Apellidos, Dirección y Teléfono de contacto del cliente.
2. Del vehículo se recogen la matrícula, el modelo y el color, también
se registra la fecha de entrada del vehículo en el taller y su hora.
3. Una vez registrado, se le asigna un que se encuentre disponible
que se encargará de elaborar la hoja de ruta de trabajo de
reparación y o mantenimiento
4. El empleado asignado que realiza la reparación irá registrando las
acciones adelantadas y los repuestos que han sido necesarios para
llevar a cabo la reparación y el precio de la mano de obra.
5. Una vez terminada la reparación, se generará la correspondiente
factura para el cliente. La factura, por tanto, contiene todos los
datos del cliente, los datos del empleado al que ha sido asignado y
el desglose de qué repuestos se han utilizado con su precio por
unidad, el precio de la mano de obra. A este total se le aplica el
19% de IVA para así imprimir la factura que será entregada al
cliente.
12
A continuación, se describe las entidades identificadas en el modelo

conceptual:
La tabla Servicio contiene el conjunto de registros que define la
información de referencia de la Base de Datos.
La tabla Cliente En esta tabla se definen los datos de documento,

nombres, apellidos, teléfono y dirección.
La tabla Vehículo en esta se definen los atributos, matricula, color y

modelo, fecha de ingreso y hora de ingreso y por lo tanto son valores de
código. La tabla de empleado indica si este se encuentra disponible o
no
La tabla Repuesto contiene el conjunto de referencia, descripción,

precio y marca, por último, se tiene la tabla Horas de servicio que
indica las horas realizadas de mantenimiento y su descripción y factura
que contiene los registros claves del cliente, servicio, vehículo,
empleado, repuestos horas laboradas y el registro de utilidad estimada y
el IVA del 19% sobre el total del valor.
2. Construcción del modelo conceptual
Buscaremos un diseño independiente de la tecnología que vamos a

implementar y que contemple todos los aspectos mencionados en el
enunciado, especialmente que soporte la totalidad las funcionalidades y
consultas requeridas.
13
Figura 1
Diseño Conceptual: Modelo Entidad Relación, notación Chen
Hora de
Documento Apellidos Nombre Matrícula
ingreso
Servicio Registra Cliente Ingresa Automovil
Fecha de
Teléfono Dirección Color Módelo
Asigna ingreso
Horas de Horas
empleadas
servicio Utilidad Horas
Estimada empleadas
Empleado Registra Crea Factura
Repuestos IVA del 19%

Repuesto
Referencia Descripción Marca Precio
La figura 1 muestra el Modelo Entidad Relación de la actividad en contexto, con notación Chen.
3. Proceso de normalización
3.1. Base de datos no normalizada
La normalización de la Base de Datos es un factor muy importante en la

construcción del modelo de administración del Taller de Mecánica. Sin
embargo, es un proceso de organización que se basa en optimizar
nuestro sistema hacia el futuro y no tenga ningún inconveniente cuando
nuestra base de datos contenga un buen número de registros.
Para mejorar el desempeño de la base de datos, así como evitar

redundancia en la información que contiene y, en consecuencia, generar
14
condiciones para un mejor diseño, se debe conocer las formas de

normalización y condiciones en las que la desnormalización es
recomendable.
Tabla 1
Datos no normalizados
Tabla Servicio
No Nombre Campo Tipo Longitud Tipo llave
Clave
N01 Numero servicio Numeric 30
principal
N02 Fecha_ingreso_SEV Date 50
N03 Hora_Ingreso_SEV Dateate 20
N04 Documento_EMP Numeric 20 Llave Foranea
Tabla Cliente
Clave
C01 Documento_ID Numeric 30
principal
C02 Nombre_ID Varchar 50
C03 Apellidos_ID Varchar 50
C04 Telefono_ID Numeric 10
C05 Direccion_ID Varchar 80
Tabla Vehículo
Clave
V01 Matricula_ID Varchar 10
principal
V02 Color_ID Varchar 30
V03 Modelo_ID Date 20
Tabla Empleado
Clave
E01 Documento_EMP Numeric 30
principal
E02 Disponible_EMP Varchar 50
E03 No_disponible_EMP Varchar 50
Tabla Hora de Servicio
Clave
H01 Numero_SEV Numeric 30
Foránea
15
H02 Horas_FACT Numeric 20

H03 Descripcion_FACT Varchar 100
Tabla Repuesto
Clave
R01 Referencia_REP Numeric 20
Principal
R02 Descripción Varchar 100
R03 Marca Varchar 100
R04 Precio Varchar 50
Tabla Factura
Clave
F01 Numero_FAC Numeric 30
Principal
Clave
F02 Numero_SEV Varchar 100
Foránea
Clave
F03 Documento_ID Varchar 30
Foránea
Clave
F04 Matricula_ID Numeric 10
Foránea
Clave
F05 Horas_FACT Numeric 20
Foránea
Clave
F06 Referencia_REP Numeric 20
Foránea
Clave
F07 Precio Varchar 50
Foránea
F08 Utilidad_EST Varchar 50
F09 IVA_19 Varchar 20
La tabla 1 muestra los datos no normalizados
3.2. Primera Forma Normal (1FN)
Este proceso es el principal y trata de completar unos pasos o procesos

que a continuación detallaremos.
1. Primer paso consistió en Eliminar los campos repetitivos de las

tablas individuales.
2. Se identificó cada campo de datos relacionados con una clave
primaria
16
Para asegurarnos que la normalización esta correcta, debemos

considerar los siguientes aspectos:
1. Que los Atributos o datos deben ser atómicos. Un atributo es

atómico si los elementos son indivisibles, mínimos en su
expresión.
2. La tabla debe de contener una clave primaria única.
3. La clave primaria no debe de contener atributos nulos. Podemos
darle solución con la opción (Auto incremento)
4. Nuestra tabla no debe existir variación en el número de columnas.
5. Los campos no clave deben identificarse por la clave (Dependencia
Funcional).
6. 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 en las consultas SQL.
7. La tabla normalizada no puede tener múltiples valores en una
determinada columna.
8. Los datos deben de ser atómicos.
En este caso se determinó simplificar algunos elementos de las

entidades Servicio y Horas de servicio para no redundar y optimizar los
tiempos de la Base de Datos, de igual manera integrar la clave foránea
Matricula_ID para permitir que un cliente pueda tener múltiples servicios
teniendo en cuenta que el mismo puede poseer distintos vehículos.
En la entidad factura se suprime la clave foránea Precio y

Documento_ID para garantizar rapidez en el acceso a los datos y
simplificando de esta manera el proceso. De esta manera la base de
datos en Primera Forma Normal queda de la siguiente manera.
17
Tabla 1
Primera Forma Normal
Tabla Servicio
Clave
N01 Numero_SEV Numeric 30
principal
N02 Matricula_ID Varchar 10 Clave Foránea
N05 Documento_EMP Numeric 20 Clave Foránea
N06 Horas_FACT Numeric 20
N07 Descripcion_FACT Varchar 100
Tabla Cliente
Clave
principal
Tabla Vehículo
Clave
principal
Tabla Empleado
Clave
principal
Tabla Repuesto
18
Clave
Principal
Tabla Factura
Clave
Principal
Clave
Foránea
Clave
Foránea
Clave
Foránea
Clave
Foránea
Clave
Foránea
La tabla 2 muestra los datos en primera forma normal para la entidad Servicio y la entidad
Factura
3.3. Segunda Forma Normal (2FN)
Pasamos a la segunda fase y debemos cumplir los siguientes puntos:
1. Crear tablas separadas para aquellos grupos de datos que se

aplican a varios registros.
2. Relacionar estas tablas mediante una clave foránea.
Para asegurarnos que estamos en la segunda fase 2FN, tenemos que

haber cumplido la primera fase y sus pasos. Además, si sus atributos no
19
principales dependen de forma completa de la clave principal de una

determinada tabla.
Para este caso tenemos en cuenta la siguiente normalización y es la que

corresponde a que teniendo en cuenta que existe múltiples repuestos
que puede ser requeridos por la misma entidad servicio por la cual se
incluye el atributo Total_REP que corresponde a la sumatoria de todos
los repuestos cargados por la entidad Empleado.
De igual manera se creó la entidad Servicio Repuesto con el fin de

incluir los atributos de Cantidad y Precio Unitario que no estaban
incluidos de manera inicial y que genera demoras en el acceso a la
información de servicio, de esta manera se busca optimizar procesos
Tabla 2
Segunda Forma Normal
Tabla Servicio
Clave
principal
Tabla Cliente
Clave
principal
20
Tabla Vehículo
Clave
principal
Tabla Empleado
Clave
principal
Tabla Repuesto
Clave
Principal
R05 Total_REP Varchar 50
Tabla Servicio – Repuesto

S01 Servicio_ID Interchar 30 Clave Foránea
S02 Repuesto_ID Varchar 50 Clave Foránea
S03 Cantidad Interchar 30
S04 Precio_unitario Interchar 10
Tabla Factura
Clave
Principal
Clave
Foránea
Clave
Foránea
21
Clave
Foránea
Clave
Foránea
Clave
Foránea
La tabla 4 muestra los datos en segunda forma normal para la entidad Servicios Repuestos
3.4. Tercera Forma Normal (3FN)
Una vez cumplidos las formas normales 1FN y 2FN seguimos el proceso
de normalización de la Base de Datos para la administración de un taller
mecánico establecemos las reglas para simplificar aún más la base de
datos teniendo en cuenta las siguientes reglas.
1. Eliminar aquellos campos que no dependan de la clave primaria.

2. Ninguna columna puede depender de una columna que no tenga una
clave primaria.
3. No puede haber datos derivados.
Hay que tener en cuenta que un registro está en la Segunda o Tercera

Forma Normal si todos los campos son parte de la clave o proveen un
dato (un valor simple) acerca de exactamente el campo clave y ningún
otro campo.
En este punto la normalización de la Base de Datos se definen

elementos esenciales para su optimización dicho esto se establecieron
nuevos atributos para fortalecer las relaciones entre las entidades y así
lograr mejores resultados en las búsquedas y la simplificación de
procesos, que permite reducir en buena media los tiempos.
22
Tabla 3
Tercera Forma Normal
Tabla Servicio
Clave
principal
Tabla Cliente
Clave
principal
Tabla Vehículo
Clave
principal
Tabla Empleado
Clave
principal
Tabla Repuesto
R01 Referencia_REP Numeric 20 Clave
23
Principal
R05 Total_REP Varchar 50
Tabla Servicio – Repuesto

S01 Servicio_ID Interchar 30 Clave Foránea
S02 Repuesto_ID Varchar 50 Clave Foránea
S03 Cantidad Interchar 30
S04 Precio_unitario Interchar 10
Tabla Factura
Clave
Principal
Clave
Foránea
Clave
Foránea
Clave
Foránea
Clave
Foránea
Clave
Foránea
La tabla 4 muestra los datos en tercera forma normal para la entidad
En conclusión, al proceso de normalización se abordaron aspectos

conceptuales básicos relacionados con las formas de normalización,
generalmente utilizadas en el análisis, desarrollo e implementación de
sistemas de bases de datos (1FN, 2FN y 3FN); además, particularidades
y consideraciones que el analista evaluó para decidir normalizar a mayor
24
grado una base de datos, mantener su forma normal actual o la

desnormalización en un modelo relacional.
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.
La Desnormalización
Otro proceso a tener en cuenta en la optimización de una Base de Datos

en este caso la del taller de mecánica es la desnormalización, en este
caso las reglas de normalización no consideran el rendimiento.
En algunos casos es necesario considerar la desnormalización para

mejorar el rendimiento. La misma consiste en la duplicación
intencionada de columnas en varias tablas, lo cual aumenta la
redundancia de datos.
La normalización crea más tablas al avanzar hacia formas normales más

altas, sin embargo, a mayor número de tablas, mayor número de
combinaciones al recuperar los datos; lo que contribuye a la
ralentización de las consultas. Por esta razón, para mejorar la velocidad
de determinadas consultas, se pueden anular las ventajas de la
integridad de datos y devolver la estructura de los datos a una forma
normal inferior.
25
Adicionalmente, Coronel, Morris y Rob (2011), al referir al proceso de

desnormalización, señalan que la unión de muchas tablas requiere
operaciones de entrada/salida (I/O) y lógica de procesamiento adicional
en el disco, con lo que se reduce la velocidad del sistema. Por lo tanto,
pueden existir circunstancias fortuitas que permitan algún grado de
desnormalización para incrementar la velocidad de procesamiento.
Debemos tomar en cuenta que la ventaja de una mayor velocidad de

procesamiento debe evaluarse cuidadosamente contra la desventaja de
datos anómalos.
4. Construcción del modelo lógico
En este cuarto punto iniciamos la fase de construcción del modelo lógico

de la Base de Datos para la administración de un taller de mecánica
Aquí los nombres ya se han normalizado siguiendo los estándares
corporativos y el prefijo asignado (INV). Se indican todas las columnas
de la tabla y se define el tipo de los datos, así como las claves primarias
y externas y las posibles restricciones (PK, FK, NOT NULL,).
La etapa de diseño lógico parte de las especificaciones del sistema para

diseñar una solución independiente de la tecnología, que después se
refinará y se implementará en etapas posteriores del desarrollo. Si nos
centramos en la parte de datos del diseño lógico, partiremos de la parte
de la especificación que corresponde a la modelización conceptual del
dominio de la aplicación, para obtener un esquema de la base de datos
expresado en un lenguaje correspondiente a algún modelo lógico de
base de datos, pero sin adoptar una versión concreta de ningún sistema
de gestión de base de datos (SGBD) ni entrar en detalles de
26
optimización o refinamiento de la base de datos, que se dejarán para

etapas posteriores de desarrollo.
De esta manera, les estamos brindando elementos de orden a nuestra

Base de Datos y un enfoque que principalmente busca apoyar y ayudar
a los sistemas de información mostrando el formato y la definición de
los diferentes datos involucrados.
En el caso de la Base de datos del taller de Mecánica ayuda a evitar la

redundancia de datos. La información almacenada en los modelos de
datos es de gran importancia para las empresa porque dicta las
relaciones entre las tablas de la base de datos, las claves externas y los
eventos involucrados.
4.1. Esquema relacional
A partir de la normalización de la base de datos nos encontramos con

una base de datos optimizada. Es así que en el desarrollo de la actividad
y en aras de proporcionar una ventaja competitiva a la organización
hemos encontrado ciertas ventajas que nos permiten llegar a un buen
nivel de optimización de la Base de Datos.
1. El objetivo principal de un modelo de datos es asegurarse de
que los objetos de datos ofrecidos por el equipo funcional se
representen con precisión.
2. El modelo de datos es lo suficientemente detallado para ser
utilizado para construir la base de datos física.
3. La información en el modelo de datos se puede utilizar para
definir la relación entre tablas, claves primarias y externas y
procedimientos almacenados.
27
4. Este modelo de datos ayuda a las empresa a comunicarse

dentro y entre los distintos procesos por el cual pasa un
vehículo desde su ingreso hasta su salida después de un
mantenimiento o reparación.
5. El modelo de datos ayuda a documentar las asignaciones de
datos en el proceso ETL
6. Ayuda a reconocer las fuentes de datos correctas para poblar el
modelo.
En este caso elaboramos un diseño optimizado de nuestras bases de

datos que muestra el nivel de optimización y el orden que han adquirido
los datos desde su concepción y que podemos ver en la siguiente figura.
Figura 2
Diseño Conceptual: Modelo Entidad Relación, notación Chen
La figura 2 muestra el Diagrama Relacional de la actividad en contexto, con notación
28
5. Diseño Físico
El diseño físico de la base de datos optimiza el rendimiento a la vez que

asegura la integridad de los datos al evitar repeticiones innecesarias de
datos. Durante el diseño físico, se transforman las entidades en tablas,
las instancias en filas y los atributos en columnas.
Una vez completado el diseño lógico de la base de datos, se pasa al

diseño físico. El personal que realiza el diseño debe tomar decisiones
que afectan al diseño físico, algunas de las cuales se listan a
continuación.
1. Cómo convertir entidades en tablas físicas

2. Qué atributos utilizar para las columnas de las tablas físicas
3. Qué columnas de las tablas deben definirse como claves
4. Qué índices deben definirse en las tablas
5. Qué vistas deben definirse en las tablas
6. Cómo desnormalizar las tablas
7. Cómo resolver relaciones de varios con varios
8. Qué diseños pueden beneficiarse del acceso hash
El diseño físico es el momento en que se abrevian los nombres que se

han elegido durante el diseño lógico. Es necesario supervisar
continuamente las características de rendimiento e integridad de los
datos de la base de datos a medida que pasa el tiempo. Muchos factores
necesitan mejoras periódicas en el diseño físico.
El resto de esta información incluye información valiosa que puede

ayudarle a crear y mejorar el diseño físico de la base de datos. Sin
embargo, esta tarea generalmente requiere tener más experiencia en
29
DB2 para z/OS que la que probablemente tienen la mayoría de los

lectores de esta información de nivel introductorio.
5.1. Diccionario de datos
Un diccionario de datos es un conjunto de definiciones que contiene las

características lógicas y puntuales de los datos que se van a utilizar en
el sistema que se programa, incluyendo nombre, descripción, alias,
contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se
necesita el acceso inmediato a la información, se desarrolla durante el
análisis de flujo de datos y auxilia a los analistas que participan en la
determinación de los requerimientos del sistema, su contenido también
se emplea durante el diseño.
Tabla 4
Diccionario de datos
30
Tabla 5
Diccionario de datos
TABLA O
ATRIBUTO O
TABLA TIPO DE DATO NULO LONGITUD LLAVE DESCRIPCIÓN ENTIDAD
CAMPO
FORANEA
NOT Clave
Numero_SEV Numeric 30
NULL principal
NOT Clave
Matricula_ID Varchar 10 Entidad Vehículo
NULL Foránea
NOT
Fecha_ingreso_SEV Date 50
NULL
NOT
Servicio Hora_Ingreso_SEV Dateate 20
NULL
NOT
Documento_EMP Numeric 20
NULL
NOT
Horas_FACT Numeric 20
NULL
NOT
Descripcion_FACT Varchar 100
NULL
NOT Clave
Documento_ID Numeric 30
NULL principal
NOT
Nombre_ID Varchar 50
NULL
NOT
Cliente Apellidos_ID Varchar
NULL
50
NOT
Telefono_ID Numeric 10
NULL
NOT
Direccion_ID Varchar 80
NULL
NOT Clave
Matricula_ID Varchar 10
NULL principal
NOT
Vehículo Color_ID Varchar
NULL
30
NOT
Modelo_ID Date 20
NULL
Empleado Documento_EMP Numeric NOT 30 Clave
NULL principal
31
NOT
Disponible_EMP Varchar 50
NULL
NOT
No_disponible_EMP Varchar 50
NULL
NOT Clave
Referencia_REP Numeric 20
NULL Principal
NOT
Descripción Varchar 100
NULL
NOT
Repuesto Marca Varchar
NULL
100
NOT
Precio Varchar 50
NULL
NOT
Total_REP Varchar 50
NULL
NOT Clave
Servicio_ID Interchar 30 Entidad Servicio
NULL Foránea
NOT Clave
Servicios Repuesto_ID Varchar 50 Entidad Repuesto
NULL Foránea
– NOT
Repuestos Cantidad Interchar 30
NULL
NOT
Precio_unitario Interchar 10
NULL
Factura NOT Clave
Numero_FAC Numeric 30
NULL Principal
NOT Clave
Numero_SEV Varchar 100 Entidad Servicio
NULL Foránea
NOT Clave
Documento_ID Varchar 30 Entidad Cliente
NULL Foránea
NOT Clave
Matricula_ID Numeric 10 Entidad Vehículo
NULL Foránea
NOT Clave
Horas_FACT Numeric 20 Entidad Servicio
NULL Foránea
NOT Clave
Referencia_REP Numeric 20 Entidad Repuesto
NULL Foránea
NOT
Utilidad_EST Varchar 50
NULL
NOT
IVA_19 Varchar 20
NULL
La tabla 5 muestra El diccionario de datos
32
5.2. Reglas de negocio
Las reglas de negocio se pueden considerar como cualquier restricción,

necesidad, requerimiento, o actividad especial que debe ser verificada al
momento de intentar grabar información, borrar, actualizar o consultar
la ya existente; las mismas son impuestas por los usuarios o los
administradores de la base de datos.
En el caso que nos atañe se puede definir un campo o una tabla que
contenga información relacionada los clientes a los que se les vende
algún determinado repuesto o las horas que pueden ser facturados
durante un mantenimiento o reparación.
Se han llamado reglas de negocio desde la perspectiva de los datos

(Castillo, 2014), a las reglas que están involucradas en las operaciones
sobre la base de datos del negocio, y presenta la siguiente clasificación
en forma de patrones de reglas:
 Restricción: Obliga a que se cumplan los requisitos del negocio,

contribuyendo a preservar la integridad del mismo.
 Cómputo: Su objetivo es calcular un valor determinado en el
negocio, y su resultado es numérico. Este patrón comparte
grandes semejanzas con el patrón de clasificación.
 Clasificación: Organiza el conocimiento básico del negocio
contribuyendo claramente al significado de conceptos, este patrón
es conocido también como una regla de definición.
 Notificación: Este patrón informa a los usuarios autorizados del
negocio sobre algún conocimiento básico en tiempo real, no
33
restringe estados del negocio, solo lo informa para que se tomen

las medidas pertinentes.
Los patrones de las Reglas de Negocio son:

 Patrón de Restricción <determinante><sujeto> (no puede
tener <características>) | (puede tener <características> solo si
<hechos>).
 Patrón de Cómputo <determinante><resultado> [en <sujeto>
[para <atributo>] es calculado como <algoritmo>.
 Patrón de Clasificación <determinante><sujeto> [no] es
definido como <clasificación> [ (si | a menos que)
<característica>].
 Patrón de Notificación Notificar <mensaje> si <hecho>.
Donde: <determinante>: Es el determinante para cada sujeto, por

ejemplo: Una, Uno, El, La, Cada, Todos. Según el mejor sentido en la
redacción.
<sujeto>: Es una entidad en la Base de Datos del negocio o una
clasificación de la misma.
<hecho>: Hechos relativos al estado o comportamiento de la Base de
Datos del negocio, incluyendo o no al sujeto.
<característica>: Describe las características del sujeto en el negocio,
tanto internas como relacionadas con otras entidades. Pueden incluir
hechos con el fin de caracterizar al sujeto.
<resultado>: Cualquier valor, no necesariamente numérico, que tiene
algún significado en el negocio. El resultado es usualmente el valor del
atributo de un objeto del negocio.
<algoritmo>: Definición de una expresión matemática para obtener el
valor de un resultado; normalmente expresada utilizando combinaciones
de términos del negocio junto a constantes disponibles.
34
<clasificación>: Definición de un término del negocio. Típicamente

define el valor de un atributo o un subconjunto de objetos en una clase
existente.
<mensaje>: Mensaje de información entre comillas para usuarios
autorizados del negocio.
5.2.1. Productividad en las transacciones
Una Transacción es un conjunto de operaciones que forman una única

unidad lógica de trabajo. Aunque se realicen varias operaciones
(actualizaciones, consultas, eliminaciones, etc) desde el punto de vista
del usuario la operación es única. Las transacciones deben de cumplir
con las siguientes propiedades (ACID) para garantizar la integridad de
los datos:
 Atomicidad: Todas las operaciones se realizan o ninguna.

 Consistencia: Los invariantes de la BD se conservan antes y
después de la ejecución de la transacción
 Aislamiento: No importa que se ejecuten transacciones
concurrentemente, desde el punto de vista del usuario lucen
secuenciales (unas no afectan la ejecución de las otras)
 Durabilidad: Los cambios comprometidos perduran en el tiempo
(número es específico de transacciones que llegan a ser
procesadas en un intervalo de tiempo, el cual normalmente se
suele medir en segundos o minutos en la base de datos.)
Técnicamente las transacciones en la Base de Datos del taller de

mecánica delimitan un conjunto de operaciones (es decir, sentencias
SQL), que son procesadas como un todo, de forma que las operaciones
que están incluidas dentro de esas transacciones base de datos se
35
validan (commit) o se cancelan (rollback) como una única operación.

Gracias a la normalización y a un Base de Datos optimizada se se logra
cumplir con las propiedades mencionadas. De igual manera se debe
tener en cuenta a futuro la capacidad de escalado de la Base de Datos
como un activo sumamente valioso para la empresa con cargas de
trabajo de alto valor y con muchas transacciones.
Como opción vemos a MySQL como un SGBD que puede servir como
una buena solución general, ya que es capaz de manejar grandes
cantidades de tráfico y puede escalar lecturas en forma de "read-
slaves"( Consiste en replicar las consultas de actualización en una base
de datos maestra sobre una o varias bases de datos esclavas (slave), de
manera que tengamos una copia de las mismas a lo largo del tiempo).
Además, hay cargas de trabajo que consideramos de alto valor, que

requieren una base de datos que puede proporcionar coherencia
inmediata y no consistencia final.
5.2.2. Tiempo de respuesta
El tiempo de respuesta es óptimo ya que responde de manera eficiente

las consultas ya cargas de trabajo de transacciones pesadas requieren
una base de datos que puede proporcionar escalabilidad alta.
Vemos a la empresa con cargas de trabajo de alto valor y alta número

de transacciones que requiere capacidad de proporcionar escalabilidad
tanto en lecturas como escrituras, garantizando atomicidad,
consistencia, aislamiento y durabilidad en cada transacción. Esto es
importante porque en el pasado, ejecutar una operación de base de
datos exitosa era proporcionar alta disponibilidad y velocidad, pero hoy
36
en día las empresas que manejan cargas de trabajo mixtas tienen otros
criterios a considerar.
5.2.3. Espacio en Disco
Mínimo gracias a la simplificación de acciones que permite almacenar

datos. Los mismos constituyen la BD están almacenados físicamente en
un medio de almacenamiento en el ordenador; más concretamente en
almacenamiento secundario de disco magnético, que es el soporte más
difundido para almacenar ficheros de bases de datos en línea, por varias
razones: La primera corresponde a que las BD suelen consistir en
grandes cantidades de información permanente, cuyo tamaño no cabe
en memoria principal y lo segundo el almacenamiento secundario es
más difícil que ocurra un fallo que suponga la pérdida de datos, además
de tener en cuenta un factor importante el cual corresponde a que su
coste es inferior.
De igual manera para el almacenamiento físico Los datos en disco se

organizan en ‘Ficheros’ de ‘Registro’. Un registro es una colección de
valores o elementos de información relacionados entre sí (que tienen
que ver con un mismo concepto de la realidad). Los registros describen
‘entidades’ y sus ‘atributos’. Cada atributo corresponde a un campo del
registro, que toma valores de cierto tipo de datos.
Es así que los registros se almacenan de forma tal que sea posible
recuperarlos (leerlos) de forma eficiente siempre que se necesiten.
Debemos de recordar que un disco magnético está dividido en pistas, y
éstas en sectores. La división de una pista en bloques de igual tamaño
(páginas) la realiza el Sistema Operativo cuando da formato al disco.
5.2.4. Tipos de archivos
37
Los archivos pueden ser usados para guardar datos durante un periodo
indefinido de tiempo o pueden ser usados para guardar datos
temporalmente para un propósito específico.
Los tipos de archivos son: archivos maestros y los archivos de tablas

que son usados para guardar datos durante un periodo largo, archivos
temporales son llamados por lo general: archivos de transacciones,
archivos de trabajo o archivos de reporte.
Archivos Maestros: Los archivos maestros contienen registros de un

grupo de entidades. Los atributos pueden ser cambiados
frecuentemente, pero los registros son relativamente permanentes.
Estos tienden a tener grandes registros que contienen toda la

información acerca de una entidad de datos. Cada registro contiene, por
lo general, una llave primaria y varias llaves secundarias.
Frecuentemente estos archivos son guardados como archivos indexados
o archivos secuenciales con índices. Ejemplos de archivos maestros
incluyen registros de pacientes, registros de clientes, un archivo de
personal o un archivo de inventario de partes.
Archivos de tablas: Contienen datos usados para calcular más datos o

medidas de desempeño. Por ejemplo, una tabla de tarifas postales para
determinar el costo del envío de un paquete, Una tabla de impuesto,
etc. Estos tipos de archivos por lo regular son leídos por un solo
programa.
Archivos de transacciones: se usan para capturar cambios que

actualizan los archivos maestros y para producir reportes. Por ejemplo,
un archivo maestro de suscriptores de periódicos, puede tener un
38
archivo de transacción que contengan el código y nombre del suscriptor,

código de la transacción, tal como E, para extender la suscripción, C
para cancelarla o D para cambio de dirección. Así se necesita solo dar la
información relevante cuando se requiera. Por lo cual los archivos de
transacciones son mantenidos por lo general, a una longitud mínima.
Además, estos pueden contener varios tipos de registros diferentes.
Archivos de trabajo: Los programas puede ejecutarse más

eficientemente si se usan archivos trabajo. Un ejemplo de archivos de
trabajo es aquel que ha sido reordenado para que los registros puedan
ser accedidos más rápidamente.
Archivos de reporte: Cuando es necesario ejecutar un programa que

imprima información y no existe la impresora o está ocupada, se usa un
archivo de reporte. El enviar la salida a un archivo es vez de a una
impresora es llamado spooling, posteriormente cuando el dispositivo
esté listo se puede imprimir la información del archivo de reporte.
Para tener en cuenta cuando los registros están físicamente en orden en

un archivo se dice que es un archivo secuencial. Cuando se actualizan
estos archivos es necesario recorrer todo el archivo. Debido a que los
registros no pueden ser insertados en las partes medias, por lo general
el archivo es copiado en el proceso de actualización.
Nuestra Base de Datos genera archivos maestros, de tablas, de trabajo

y de reporte entre los que se destacan factura con los números de
servicios y los valores en pesos de las horas trabajadas y los repuestos
asignados al proceso de mantenimiento o reparación
5.2.5. Memoria principal
39
Una base de datos en memoria (IMDb, según sus siglas en inglés, y

también conocida como base de datos en memoria principal o MMDB) es
una base de datos cuyos datos están almacenados en la memoria
principal para facilitar tiempos más rápidos de respuesta.
En nuestro caso los datos de origen se cargan a la memoria del sistema

en un formato comprimido no relacional. Esto permite que las bases de
datos en memoria optimizan el trabajo relacionado con el procesamiento
de consultas. En términos generales una IMDb es un tipo de base de
datos analítica, que es un sistema de solo lectura que almacena datos
históricos sobre indicadores para aplicaciones de inteligencia
empresarial/análisis de negocios (BI/BA), usualmente como parte de un
almacén de datos o un data mart.
Estos sistemas permiten a los usuarios ejecutar consultas e informes

sobre la información contenida, que se actualiza regularmente para
incorporar datos de transacción recientes de los sistemas operativos de
una organización. Además de brindar tiempos extremadamente rápidos
de respuesta a consultas, la analítica en memoria puede reducir o
eliminar la necesidad de indexar datos y almacenar datos preagregados
en cubos OLAP o tablas agregadas. Esta capacidad reduce los costos de
informática y permite una implementación más rápida de aplicaciones
de BI/BA. Al estar optimizada la base de datos el consumo es mínimo.
5.2.6. Criterios para selección de SGBD
Se debe tener en cuenta a la hora de elegir un Sistema de Gestión de

Base de datos los siguientes criterios: que sea fácil de usar, la seguridad
de los datos, la funcionalidad y la capacidad de integración. de igual
40
manera consideramos que debe contar con muy buen soporte y

desarrollo, además de escalabilidad y por último su costo e idoneidad.
6. SQL
6.1. Creación de la base de datos
Una vez establecido el SGBD se debe realizar la creación de la Base de

Datos para la Administración de un Taller de Mecánica. Para eso
utilizaremos el T-SQL es el lenguaje de manipulación de los datos en el
SQL Server, cada SGBD tiene un lenguaje propio, así, pues si utilizamos
ORACLE el lenguaje de manipulación será el PL-SQL. Sin embargo, hay
un leguaje estándar llamado SQL y ese, aunque con limitantes en el
sentido que no provee muchas funciones que los propios de las SGBD
tienen, funciona en cualquier SGBD.
CREATE DATABASE TALLER MECANICA
6.2. Creación de tablas
Sintaxis básica de la sentencia CREATE TABLE de MySQL
MySQL
CREATE TABLE nombre_tabla 1
Con el código superior tenemos la sentencia estándar para crear la

tabla, solamente tenemos que poner el nombre de la tabla, nombre de
la columna y su tipo. Podemos tener una base de datos con numerosas
tablas, por lo que al crear una nueva podemos tener una existente con
41
el mismo nombre. Para evitar problemas debemos usar la sentencia ‘IF

NOT EXIST’ por ejemplo:
MySQL
CREATE TABLE IF NOT EXISTS nombre_tabla
1
Quedando una estructura similar a esta:

MySQL
(definición de la tabla, definición de columnas, tipos de columnas);
(definición de la tabla,
definición de columnas,
tipos de columnas
);
Para la definición de la tabla utilizaremos la sintaxis para definir las

diferentes definiciones que se pueden hacer sobre la misma:
MySQL
| [CONSTRAINT [nombre]] PRIMARY KEY [index_tipo] (index_col_nombre,...)
[index_option] ...
| {INDEX|KEY} [index_name] [index_tipo] (index_col_nombre,...)
[index_option] ...
| [CONSTRAINT [nombre]] UNIQUE [INDEX|KEY]
[index_name] [index_tipo] (index_col_nombre,...)
[index_option] ...
| {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name] (index_col_nombre,...)
[index_opción] ...
| [CONSTRAINT [nombre]] FOREIGN KEY
[index_nombre] (index_col_nombre,...) reference_definition
| CHECK (expr)
42
| [CONSTRAINT [nombre]] PRIMARY KEY [index_tipo] (index_col_nombre,...)

[index_option] ...
| {INDEX|KEY} [index_name] [index_tipo] (index_col_nombre,...)
[index_option] ...
| [CONSTRAINT [nombre]] UNIQUE [INDEX|KEY]
[index_name] [index_tipo] (index_col_nombre,...)
[index_option] ...
| {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name] (index_col_nombre,...)
[index_opción] ...
| [CONSTRAINT [nombre]] FOREIGN KEY
[index_nombre] (index_col_nombre,...) reference_definition
| CHECK (expr)
CONSTRAINT es una restricción, el nombre de la restricción debe ser

única en la base de datos. Estas exigen la integridad de los datos de las
columnas de la tabla.
PRIMARY KEY: Solo se puede crear una primary key por tabla, es la
clave primaria que identifica de manera única cada registro/fila de la
tabla. Por ejemplo, el documento de identidad de un nuevo cliente en el
taller.
INDEX|KEY: Ambas son sinónimas, puede haber una o varias.
Establecen los índices de la tabla con los cuales se pueden agilizar las
búsquedas en la base de datos. De esta manera se evita la búsqueda de
un parámetro por cada columna de la tabla. Es como un índice de un
libro con el que nos evitamos recorrer cada página.
UNIQUE: Es una restricción por la cual el valor de dicha columna debe
ser único y diferente al del valor de dicha columna de resto de registros.
Por ejemplo, se suele usar con las columnas declaradas como primary
key.
FULLTEXT: Es un índice que solo funciona con las columnas con formato
char, varchar, text y con almacenamiento MyISAM. Este índice facilita
las grandes búsquedas sobre texto y realiza automáticamente
43
comparaciones de texto sobre una cadena dada. Realiza búsquedas más

afinadas que la sentencia LIKE. Se ignoran las palabras con menos de 4
letras y las palabras que aparezcan en más del 50% de los registros.
FOREIGN KEY: Clave foránea, es un índice por el cual podemos
relacionar 2 tablas. Este valor debe existir en ambas tablas, por
ejemplo, el número de servicio que se establece cuando se registra un
vehículo.
6.3. Creación de funciones, procedimientos, cursores, triggers
Con base a lo vista a lo largo del desarrollo del trabajo se establece el

uso de MYSQL para desarrollar nuestra base de datos y consultando los
procedimientos se establece que el código para la elaboración de
funciones, procedimiento, cursores y triggers.
Los procedimientos o rutinas almacenadas son un conjunto de

instrucciones SQL combinadas con una serie de estructuras de control.
Se guardan en el servidor, forman parte de una base de datos, y se
accede a ellas a través de llamadas.
Los parámetros se declaran en la cabecera de la instrucción indicando si

se trata de un parámetro de entrada (in), salida (out), o ambos (inout)
El procedimiento no deja de ser una pieza de código que en ocasiones

requiere la incorporación de instrucciones para control del flujo de
código. En este caso se usan estructuras básicas como las que podemos
encontrar en cualquier lenguaje de programación: IF, REPEAT, WHILE,
LOOP, LEAVE, CASE.
44
Los cursores son estructuras temporales de almacenamiento auxiliar

muy útiles cuando se construyen procedimientos sobre bases de datos.
Para crear un cursor es necesario declararlo y definir la consulta select
que lo poblará de valores:
DECLARE nombre_cursor CURSOR FOR sentencia_select
 La sentencia SELECT no puede contener INTO.

 Los cursores no son actualizables.
 Se recorren en un sentido, sin saltos.
Se deben declarar antes de los handlers y después de la declaración de

variables
Junto con los procedimientos almacenados (PROCEDURE), SQL nos

permite crear otras estructuras programables de la misma manera
aunque con funcionalidades y naturalezas diferentes. Es el caso de las
funciones (FUNCTION) y los disparadores (TRIGGER).
Una función es un procedimiento que obligatoriamente ha de devolver

un valor:
DELIMITER //
CREATE FUNCTION total_creditos_profesores()
RETURNS int
BEGIN
DECLARE total_creditos int;
SELECT SUM(creditos) INTO total_creditos
FROM gi_profesores, gi_categorias
WHERE categoria=codigo;
RETURN total_creditos;
END
//
45
Para elaborar un Procedimientos en MYSQL se deben tener en cuenta lo

siguiente:
CREATE
[DEFINER = { user | CURRENT_USER }]
PROCEDURE sp_name ([proc_parameter[,...]])
[characteristic ...] routine_body
proc_parameter:
[ IN | OUT | INOUT ] param_name type
func_parameter:
param_name type
type:
Any valid MySQL data type
characteristic:
COMMENT 'string'
| LANGUAGE SQL
| [NOT] DETERMINISTIC
| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
routine_body:
Valid SQL routine statement
Lo mismo para las Funciones
CREATE
[DEFINER = { user | CURRENT_USER }]
FUNCTION sp_name ([func_parameter[,...]])
RETURNS type
[characteristic ...] routine_body
proc_parameter:
[ IN | OUT | INOUT ] param_name type
func_parameter:
param_name type
type:
Any valid MySQL data type
characteristic:
COMMENT 'string'
46
| LANGUAGE SQL
| [NOT] DETERMINISTIC
| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
routine_body:
Valid SQL routine statement
6.4. Consultas pertinentes según el caso
Se encontraron dificultades en algunos elementos, ya que no se cuenta

con elementos adicionales que permitan fortalecer las tablas, es el caso
del empleado que no cuenta con información más allá de su ID y que
sería importante conocer su especialidad.
7. Informe de pruebas
Inicialmente existen dificultades en la tabla Factura y el atributo de

Utilidad ya que en las reglas no se estableció si la misma corresponde a
las horas laboradas y/o a los repuestos lo que genera que su condición
sea incierta.
8. Aplicación de ACID al caso
Como se hizo el diseño de la base de datos aun no se pueden establecer

si la misma cumple en su totalidad las propiedades para garantizar la
integridad de los datos establecidos.
9. Análisis de datos
En el diseño de la BD se encontraron inconsistencias que no se

encuentran en los parámetros iniciales del ejercicio los cuales han sido
detallados, pero el caso de la utilidad representa un riesgo ya que este
elemento debe ser considera con base a los atributos horas y repuestos,
o por el contrario de manera individual, de igual manera no define el
valor o porcentaje del mismo.
47
10. Implementación física
10.1. Hardware
10.1.1. Modelo de servidor recomendado
Como no se cuenta con el volumen de datos que van a ser almacenados,

la recomendación es utilizar un servidor mixto que tenga la capacidad de
almacenamiento escalable y que garantice la integridad de la
información.
10.1.2. Almacenamiento
Usualmente se encuentran en el mercado tres tipos de almacenamiento

de bases de datos: Unidades SATA, unidades SSD y NVMe, en orden de
más lento a más rápido y de menos a más caro.
El almacenamiento afecta al rendimiento de la base de datos de dos

maneras principales: la velocidad de la consulta y la cantidad de datos
que se pueden almacenar. A la hora de elegir un medio de
almacenamiento, es importante equilibrar las necesidades y los costos.
Para hacer eso, necesita entender cómo se va a utilizar su base de
datos.
10.2. Conectividad
El objetivo es garantizar el acceso remoto a la información de la Base de

Datos por lo que se considera el uso de un servidor con acceso a la Red
de Área Local y si es necesario poder acceder a ellos de manera remota
a través de Internet.
10.3. Seguridad
48
Cuando hablamos de integridad en base de datos nos estamos refiriendo

a la completitud, la exactitud y la coherencia del conjunto de datos de
una base de datos. Podemos tener una percepción de esta integridad en
base de datos cuando vemos que entre dos instancias o entre dos
actualizaciones de un registro de datos, no hay ninguna alteración, lo
que significa que los datos están intactos y sin cambios.
De igual manera garantizar la integridad es proteger y brindar

confidencialidad en la información siguiendo la normatividad vigente en
el país para lo protección de datos personales.
11. Conclusiones
Como conclusión consideramos que se han alcanzado los objetivos

planteados en el enunciado con una solución eficiente y que ha quedado
correctamente validada y documentada.
Este trabajo ha permitido desarrollar distintos roles a lo largo del

ejercicio sobre todo en el análisis y desarrollo de la Base de Datos, sus
relaciones y cómo se puede realizar un proceso de normalización para ir
evitando errores a futuro.
Además, se ha cubierto una parte significativa los procesos de diseño y

creación de una Base de Datos. También me ha servido para valorar la
importancia de entender y definir correctamente los objetivos del
proyecto desde lo antes posible.
En este ejercicio hemos estudiado el proceso de diseño lógico como una

de las etapas del desarrollo de una base de datos para un sistema de
49
información. Este proceso parte del esquema conceptual que hemos

obtenido en la fase de especificación y genera como resultado el
esquema lógico de la base de datos.
De igual manera hemos empezado el trabajo identificando las trampas

de diseño, posibles errores que pueden haberse cometido durante el
diseño conceptual de la Base de Datos y que conviene repasar antes de
tomarlo como punto de partida del diseño lógico y estructurado.
En consideración he podido aprender sobre los distintos pasos que

deben ser tomados para el diseño e implementación de la Base de Datos
y cómo un estado óptimo nos puede proporcionar una información
coherente y lógica que se convertirá en un futuro en un factor
diferencial.
De igual manera resaltar que se contó con datos muy limitados que nos
brindó un reto poder llenar los vacíos pero que nos sirve como un
aliciente para seguir avanzando en el aprendizaje de un sistema de
información.
BIBLIOGRAFÍA BÁSICA
1. Inmon, W. (2002). Building the data warehouse. John Wiley and

Sons.
2. Kimball, R., & Ross, M. (2013). The Data Warehouse Tollkit (Third
Edition ed.). Indianapolis, United States of America: Wiley.
3. Laudon, K. C., & Laudon, J. P. (2012). Sistemas de Información
Gerencial. (L. Cruz Castillo, Ed.) Naucalpan de Juarez, México:
Pearson.
50
4. Coronel, C., Morris, S. y Rob, P. (2011). Bases de datos. Diseño,

implementación y administración. (J. H. Romo, trad.). México:
Cengage Learning.
5. Beatriz, M., & Castillo, B. Castillo, M.B., Garcell, A., Alonso, A. P.,
Paz, l. D. D. L. &
6. Castillo, M. B. B. (2014). Reglas de negocio desde la perspectiva
de los datos en bases dedatos relacionales. (Tesis doctoral),
Universidad Central "Marta Abreu" de Las Villas, Santa Clara.
51

Taller Base de Datos

Cargado por

Copyright:

Formatos disponibles

Taller Base de Datos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Taller Base de Datos

Cargado por

Copyright:

Formatos disponibles

Base de datos para la administración de un taller mecánico.

Base de datos para la administración de un taller

BASE DE DATOS PARA LA ADMINISTRACIÓN DE UN TALLER

Este documento corresponde a la elaboración de una Base de Datos

Esta Base de Datos debe proporcionar persistencia a una aplicación cuyo

Palabras claves: Base de Datos, inteligencia de negocios, relacional,

DATABASE FOR THE ADMINISTRATION OF A MECHANICAL

This document corresponds to the elaboration of a Database for the

This Database must provide persistence to an application whose

Keywords: Database, business intelligence, relational, efficiency.

10. Implementación física.............................................................................................................47

Tabla 1 Datos no normalizados.....................................................15

Figura 1 (para actualizar la numeración, botón derecho, actualizar

El mundo de hoy se está globalizando y cada vez se hace más necesario

Si un Sistema de Gestión de Base de Datos se gestiona adecuadamente,

De lo anterior surge la oferta que hace la tecnología para la solución de

El cliente es un Taller de Mecánica de vehículos. El cliente quiere que se

Estas funcionalidades aportarán un valor añadido a la empresa objeto de

conseguiremos que la información y el conocimiento sean los mayores

El objetivo es brindar una solución eficiente que pueda garantizar la

PLANTEAMIENTO DEL PROBLEMA Y PREGUNTAS DE

Como lo plantea el ejercicio académico en el taller de mecánica a diario

La falta de un sistema de información eficiente hace que los procesos se

Es por eso que nos planteamos el siguiente cuestionamiento ¿se puede

Diseñar un modelo de Base de Datos para la administración eficiente de

1. Estructurar un modelo de Base de Datos de los clientes, los

1. Identificación de entidades, atributos y relaciones

El primer paso en el desarrollo de la Base de Datos para la

1. Se registra tanto el cliente como el vehículo que trae al taller para

A continuación, se describe las entidades identificadas en el modelo

La tabla Cliente En esta tabla se definen los datos de documento,

La tabla Vehículo en esta se definen los atributos, matricula, color y

La tabla Repuesto contiene el conjunto de referencia, descripción,

2. Construcción del modelo conceptual

Buscaremos un diseño independiente de la tecnología que vamos a

Servicio Registra Cliente Ingresa Automovil

Empleado Registra Crea Factura

Repuestos IVA del 19%

Referencia Descripción Marca Precio

3.1. Base de datos no normalizada

La normalización de la Base de Datos es un factor muy importante en la

Para mejorar el desempeño de la base de datos, así como evitar

condiciones para un mejor diseño, se debe conocer las formas de

H02 Horas_FACT Numeric 20

La tabla 1 muestra los datos no normalizados

3.2. Primera Forma Normal (1FN)

Este proceso es el principal y trata de completar unos pasos o procesos

1. Primer paso consistió en Eliminar los campos repetitivos de las

Para asegurarnos que la normalización esta correcta, debemos

1. Que los Atributos o datos deben ser atómicos. Un atributo es

En este caso se determinó simplificar algunos elementos de las

En la entidad factura se suprime la clave foránea Precio y

3.3. Segunda Forma Normal (2FN)

Pasamos a la segunda fase y debemos cumplir los siguientes puntos:

1. Crear tablas separadas para aquellos grupos de datos que se

Para asegurarnos que estamos en la segunda fase 2FN, tenemos que

principales dependen de forma completa de la clave principal de una

Para este caso tenemos en cuenta la siguiente normalización y es la que

De igual manera se creó la entidad Servicio Repuesto con el fin de