DISEÑO Y ADMINISTRACION DE BASES DE

DATOS
PREPROYECTO

PROFESOR: Horacio Enrique Castillo Puente

NOMBRE: Joel Rodriguez Ramos
ID INTEGRANTE: 00691176
Planteamiento de un problema o área de mejora:
En una cadena aérea se están perdiendo datos al ingresar información de pilotos,
aviones y miembros de la tripulación desde hace 6 meses en tanto se están
extraviando los itinerarios de los vuelos, éste es un gran problema ya que trae
implicaciones al alquilar los aviones o perder rutas de vuelo.
Este problema se originó desde el principio ya que no se llevó a cabo una
estructura ni normalización de una base datos, tampoco se implementó un sistema
de gestión adecuado para la implementación de estas tablas, ya que se estaban
repitiendo datos y sin guardarse el número de vuelo y las rutas.
Dicha situación pudo detectarse ya que estaban programando el mismo avión en
dos rutas diferentes, pero en el mismo horario, por ende, los dos vuelos fueron
cancelados. Para empeorar la situación notaron que no se estaban generando los
pagos de la tripulación de forma correcta, ya que en algunos casos se estaban
pagando de más y otros no recibían pagos. Esto se debió a que la arquitectura en
la que se implementó la base de datos no era la correcta, ya que no hubo un
modelo de datos y una arquitectura Cliente / Servidor correctamente
implementada.
Tomando en cuenta esta problemática reflexiona lo siguiente:
• ¿Qué modelo de datos es el adecuado para esta base de datos?

• ¿Por qué crees que se originó este problema en la base de datos?

• ¿Por qué crees que la estructura de base de datos que está implantada no
funcionó correctamente?
Objetivo de la propuesta de Mejora

El objetivo es crear una buena arquitectura de datos para que no se originen los
problemas, iniciando con un buen modelo de datos que para mi el mas adecuado
es el relacional, ya que el modelo de base de datos más común que aún se usa
hoy en día es relacional, que almacena los datos en registros de formato fijo y
organiza los datos en tablas con filas y columnas. El tipo más básico de modelo de
datos tiene dos elementos: indicadores y dimensiones. Los indicadores son
valores numéricos, como cantidades e ingresos, que se usan en cálculos
matemáticos como suma o promedio. Las dimensiones pueden ser de texto o
numéricas. No se usan en cálculos e incluyen descripciones o ubicaciones. Los
datos brutos se definen como un indicador o una dimensión. Otra terminología
usada en el diseño de la base de datos relacional incluye "relaciones" (la tabla con
filas y columnas), "atributos" (columnas), "tuplas" (filas) y "dominio" (conjunto de
valores permitidos en una columna). Si bien hay términos adicionales y requisitos
estructurales que definen una base de datos relacional, el factor importante son
las relaciones definidas dentro de esa estructura.

Se origino este problema porque no están normalizadas las bases de datos y eso
repitió o genero redundancia de datos. Los elementos de datos comunes (o
claves) vinculan tablas y conjuntos de datos. Las tablas también se pueden
relacionar explícitamente, como las relaciones principales y secundarias, como ser
uno a uno, uno a varios o varios a varios.

Entre los fallos que pueden cometerse en el diseño de base de datos están los
relacionados con la no utilización de procedimientos almacenados para acceder a
los datos o con la falta de pruebas. Además, existen 6 errores importantes a evitar.
Son los siguientes:

1. Falta de planificación. Dado que la base de datos es la piedra angular de

casi todos los proyectos de negocios, si no se toma el tiempo de planificar
las necesidades del proyecto y cómo la base de datos las va a cumplir, es
probable que todo el proyecto se desvíe. Además, si no se toma el tiempo
para comenzar con el diseño correcto de la base de datos, se descubrirá
que cualquier cambio sustancial en las estructuras de la data base que se
necesite para seguir avanzando podría tener un gran impacto en general y
provocar aumentos de costes y retrasos en el proyecto.
2. Ignorar la necesidad de normalización. SQL fue creado para trabajar con
estructuras de datos normalizadas. La normalización es necesaria desde la
programación de bases de datos a la de aplicaciones. Resulta
extremadamente importante, no solo para facilitar el desarrollo, sino
para mejorar el rendimiento. Los índices son más efectivos cuando pueden
trabajar con el valor clave completo.
3. Estándares de denominación deficientes. Los nombres, aunque son una
elección personal, son la primera y más importante línea de documentación
para cualquier aplicación. Por eso, es preciso asegurar su coherencia. Los
nombres que se elijan no son solo para permitir identificar el propósito de
un objeto, sino para permitir que todos los futuros programadores, usuarios,
etc., comprendan rápida y fácilmente cómo una parte componente de la
base de datos estaba destinada a ser utilizada y qué datos que
almacena. Ningún usuario futuro debería necesitar leer un documento de
 500 páginas elaborado en el momento del diseño de base de datos para
determinar el significado de algún nombre raro.
4. Falta de documentación. Un modelo de datos bien diseñado no solo se
adhiere a un estándar de nomenclatura sólido, sino que también contiene
definiciones en sus tablas, columnas, relaciones e incluso restricciones
predeterminadas y de verificación, para que quede claro para todos cómo
están destinados a usarse. El objetivo debe ser proporcionar suficiente
información para que cuando se complete el diseño de base de datos y se
entregue a un programador de soporte, pueda descubrir los errores
menores y corregirlos.
5. Una tabla para contener todos los valores de dominio. Las bases de
datos relacionales se basan en la idea fundamental de que cada objeto
representa una y solo una cosa. Nunca debe haber ninguna duda sobre a
qué se refiere un dato. Al rastrear las relaciones, desde el nombre de la
columna hasta el nombre de la tabla y la clave principal, debería ser fácil
examinarlas y saber exactamente qué significa una parte de los datos. Es,
por eso mismo, mucho mejor evitar la complejidad y crear estructuras
sólidas y mantenibles, en lugar de intentar hacer la menor cantidad de
trabajo al comienzo del proyecto de diseño de base de datos.
6. No proteger la integridad de los datos. Todas las reglas de negocio
fundamentales y no cambiantes deben implementarse mediante el motor
relacional. Las reglas básicas de anulabilidad, longitud de cadena,
asignación de claves externas, etc., deben definirse en la base de datos.
Hay que tener en cuenta que existen muchas formas diferentes de importar
datos a SQL Server. Si las reglas básicas están definidas en la propia base
de datos, puede garantizarse que nunca se pasarán por alto. De esta
forma, se podrán escribir las consultas sin tener que preocuparse de si los
datos que se muestran cumplen con las reglas de negocio básicas o no.
Softwares para crear modelos de diagramas entidad – relación y realizar el
contexto y justificación del por qué la implementarías dentro del ámbito
profesional.
Lucidchart
Lucidchart es la aplicación de diagramación inteligente que reúne a los equipos
para que tomen mejores decisiones y construyan el futuro.
Canva
Canva es un software y sitio web de herramientas de diseño gráfico simplificado,
fundado en 2012. Utiliza un formato de arrastrar y soltar e incluso permite de
manera proporcionada hacer grandes y pequeñas las figuras y proporciona acceso
a más de 60 millones de fotografías y 5 millones de vectores, gráficos y fuentes.
Smart Draw
SmartDraw es una herramienta de creación de diagramas basada en la web que
utilizan los equipos para colaborar y crear diagramas de flujo, organigramas,
mapas mentales, diagramas de proyectos y otras imágenes comerciales.
Implementaría cualquier software de entidad – relación ya que nos ayudan
visualmente a entender mejor toda la arquitectura de una base de datos, y así
realizar un producto de calidad, donde no existan errores que perjudiquen la
operación.

MARCO TEORICO
a. Normalización de las bases de datos.
La normalización no es obligatoria, pero aporta las siguientes ventajas:

• El proceso de muestreo se simplifica. Se trata de simplificar el trabajo de

consulta, es decir, el usuario podrá recuperar la información deseada con
consultas relativamente sencillas.
• La integridad de los datos está garantizada. Se puede hablar de minimizar
la distorsión de la información y reducir la probabilidad de pérdida de datos.
• Se mejora la escalabilidad. Si se observan las reglas de normalización, se
forman las condiciones favorables para el crecimiento de la base de datos.
• No hay redundancia de datos. La redundancia es un problema notorio de
uso improductivo del espacio libre en el disco duro que dificulta el
mantenimiento de la base de datos. En algunos casos, este problema se
agrava por el hecho de que si es necesario alterar los registros del mismo
tipo de datos almacenados en varios lugares (tablas), el usuario tendrá que
realizar las alteraciones en todas partes, lo cual es una tarea bastante
laboriosa.
 • Ausencia de dependencias incoherentes. Las dependencias incoherentes
impiden el acceso a los datos, porque el camino hacia esa información puede
ser incorrecto e ilógico. En la tabla Ciudades es lógico buscar las ciudades,
el número de habitantes, etc., pero no las direcciones y los nombres de los
habitantes (para esta información necesitamos otra tabla): Ciudadanos

La normalización se lleva a cabo:

Para llevar la base de datos a un estado normal, es necesario:

1. Combinar los datos existentes en grupos.

2. Aclarar las relaciones lógicas entre los grupos. Para garantizar la
exactitud de los vínculos, los campos que se vinculen deben ser del mismo
tipo.

Si la tabla no está normalizada, puede almacenar la información de varias entidades

e incluir las columnas repetidas que a su vez pueden almacenar los valores
duplicados. Sin embargo, si se normaliza, cada tabla almacena información sobre
una sola entidad.
La normalización supone el uso de formas normales con respecto a la estructura
de los datos disponibles. Hay varias reglas de normalización. Cada una de ellas se
denomina forma normal (FN). Cada una de estas formas, excepto la primera,
supone que la forma normal anterior ya se ha aplicado a los datos. Cuando se
ejecuta la primera regla, la base de datos se representa en la primera forma normal
(1FN), y cuando se ejecutan las tres reglas se representa en la tercera forma normal
(3FN).
Existen siete de estas formas (niveles), pero en la práctica para la mayoría de las
aplicaciones basta con normalizar la base de datos hasta la tercera forma normal
(en sentido estricto, la base de datos se considerará normalizada cuando se le
aplique una 3FN o superior).
Es cierto, no siempre es factible ofrecer un cumplimiento total de las normas y
especificaciones porque la normalización requerirá la creación de tablas adicionales
y no siempre es aceptable o no es aceptada por los clientes. Pero si hay que romper
las reglas, hay que entender que se tendrán en cuenta todos los problemas
relacionados, incluidas las dependencias no coordinadas y la redundancia, y que
esto es aceptable para la aplicación sin romper su funcionalidad.
b. Elementos y organización de las bases de datos
La correcta elección y configuración de cada elemento determinará si la base de
datos cumple con los objetivos para los que fue diseñada o, en cambio, se
convierte en un sistema ineficiente. Los recursos destinados a cada elemento
dependerán en gran medida del tipo de base de datos y su modelo seleccionado
en la fase de diseño. Aun así, hay una serie de elementos comunes en toda
implementación:
Software

Entendemos el Software como el conjunto de programas utilizados para controlar

y tratar la base de datos. Esto incorpora la propia programación del DBMS, el
Sistema Operativo, la programación de la red que se utiliza para compartir los
datos entre los clientes y los programas de aplicación utilizados para acceder a los
datos en la DBMS.

Hardware

El hardware es la parte física de la base de datos. Comprende una gran cantidad

de aparatos electrónicos como los ordenadores, los discos duros, servidores, etc.

Datos

Como es obvio, una base de datos no tiene sentido si no tenemos datos como
recurso para almacenar. Una base de datos almacena dos tipos de datos: los
datos operativos y los metadatos. Los datos operativos se refieren a aquella
información que incluimos para almacenar y los metadatos en la información que
nos permite comprender lo que se ha almacenado.

En las bases de datos es una práctica común y recomendable incluir un

diccionario de datos, es decir, un conjunto de metadatos que brindan lógica y
comprensión a los datos almacenados para evitar errores e interpretaciones
confusas.

DMBS

Llamamos Sistema de administración de Bases de Datos o DMBS (Data Base

Management Sistema) a un programa o conjunto de programas que sirve para
acceder y gestionar nuestras bases de datos. No es ni más ni menos que el
software que sirve como enlace de comunicación entre nuestros datos y cualquier
programa informático que trabaje con ellos.

Lenguaje de acceso

Se utiliza para acceder a los datos normalmente desde la interfaz del propio
DBMS. Con el lenguaje podemos introducir nuevos datos, actualizar los ya
existentes, programar acciones y prácticamente cualquier tarea requerida en la
que intervengan los datos.

El lenguaje de comunicación con la base de datos más utilizado es SQL, aunque

cada sistema de gestión de bases de datos tiene sus variaciones. Por ejemplo,
Microsoft SQL Server utiliza Transact-SQL (T-SQL), una expansión de SQL
desarrollada por IBM.
Procedimientos

Por procedimientos entendemos al conjunto de instrucciones que se utilizan para

configurar el DMBS y su correcto funcionamiento, así como sus accesos y copias
de seguridad, etc.

Reporting

El generador de informes es un programa que extrae la información de la base de

datos y la representa visualmente en el formato configurado previamente para ser
consumido por los analistas o diferentes miembros de la organización.

c. Modelos de datos
Los tres principales modelos de datos son relacional, dimensional, y de entidad-
relación (E-R). También hay otros cuyo uso no está generalizado, incluyendo
jerárquico, en red, orientado a objetos, y multivalor. El tipo de modelo define la
estructura lógica –el modo en que se almacenan, organiza y recuperan los datos–.

1. Relacional: Aunque el enfoque es "más antiguo", el modelo de base de

datos más común que aún se usa hoy en día es relacional, que almacena
los datos en registros de formato fijo y organiza los datos en tablas con filas
y columnas. El tipo más básico de modelo de datos tiene dos elementos:
indicadores y dimensiones. Los indicadores son valores numéricos, como
cantidades e ingresos, que se usan en cálculos matemáticos como suma o
promedio. Las dimensiones pueden ser de texto o numéricas. No se usan
en cálculos e incluyen descripciones o ubicaciones. Los datos brutos se
definen como un indicador o una dimensión. Otra terminología usada en el
diseño de la base de datos relacional incluye "relaciones" (la tabla con filas
y columnas), "atributos" (columnas), "tuplas" (filas) y "dominio" (conjunto de
valores permitidos en una columna). Si bien hay términos adicionales y
requisitos estructurales que definen una base de datos relacional, el factor
importante son las relaciones definidas dentro de esa estructura. Los
elementos de datos comunes (o claves) vinculan tablas y conjuntos de
datos. Las tablas también se pueden relacionar explícitamente, como las
relaciones principales y secundarias, como ser uno a uno, uno a varios o
varios a varios.
2. Dimensional: Menos rígido y estructurado, el enfoque dimensional
favorece una estructura de datos contextual que está más relacionada con
el uso o contexto de negocio. Esta estructura de base de datos está
optimizada para consultas online y herramientas de almacenamiento de
datos. Los elementos de datos críticos, como una cantidad de transacción,
por ejemplo, se denominan "hechos" y van acompañados de información de
referencia llamada "dimensiones", ya sea el ID de producto, el precio
unitario o la fecha de transacción. Una tabla de hechos es una tabla
primaria en un modelo dimensional. La recuperación puede ser rápida y
eficiente, con datos para un tipo específico de actividad almacenados
 juntos, pero la falta de vínculos de relación puede complicar la recuperación
analítica y el uso de los datos. Dado que la estructura de datos está
vinculada con la función de negocio que produce y usa los datos, la
combinación de datos producidos por sistemas diferentes (en un almacén
de datos, por ejemplo) puede ser problemática.
3. Rico en entidades (E-R): Un modelo E-R representa una estructura de
datos de negocio en forma gráfica que contiene cuadros de varias formas
para representar actividades, funciones o "entidades" y líneas para
representar asociaciones, dependencias o "relaciones". El modelo E-R se
usa para crear una base de datos relacional con cada fila que representa
una entidad y los campos de esa fila contienen atributos. Como en todas las
bases de datos relacionales, los elementos de datos "clave" se usan para
vincular tablas.

d. Sistemas de gestión de bases de datos

La gestión de bases de datos no es una entidad singular, sino que más bien se
trata de una serie de acciones (y para algunos, un sistema dedicado) que controla
datos empresariales durante el ciclo de vida. A medida que los datos aumentan,
las empresas han descubierto que la gestión de bases de datos es una necesidad
para manipular esta afluencia a fin de evitar un rendimiento deficiente de las
aplicaciones y reducir cualquier impacto en el cumplimiento y la continuidad.

Existen varias técnicas y acciones bajo el paraguas de "gestión de bases de

datos" que una empresa puede adoptar para reducir o prevenir los impactos
negativos del crecimiento exponencial e incontrolado de los datos.

A continuación se incluye una lista de algunas tareas de gestión comunes y de

protección para bases de datos:

• Supervisar el rendimiento de las aplicaciones y sus datos y ajustar según

sea necesario
• Planificar los requisitos de almacenamiento y de crecimiento de la
capacidad
• Establecer una potente solución de respaldo y recuperación ante desastres
• Archivar, dividir, replicar y enmascarar datos

BIBLIOGRAFIA
Castañeda, M. P. (n.d.). Normalización de Bases de Datos. Unam.mx. Retrieved

March 26, 2023, from

https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/872

/mod_resource/content/7/Contenido/index.html

Liuvanis, R. V. (2014). Conceptos Básicos En La Enseñanza de Los Sgbd. Editorial

Academica española.

Timarán Pereira, R., & Millán, M. (2011). Extensión del Lenguaje SQL con Nuevas

Primitivas para el Descubrimiento de Reglas de Asociación en una

Arquitectura Fuertemente Acoplada con un SGBD. Ingeniería y

Competitividad, 7(2), 53–63. https://doi.org/10.25100/iyc.v7i2.2518

Wikipedia, F. (2011). Sgbds: Mapeamiento Objeto-Relacional, OLAP, Oracle,

Microsoft SQL Server, Microsoft Access, PostgreSQL, dBASE, Db4o,

MySQL. Books LLC, Wiki Series.

Yanet Espinal Mart N, & Puebla, M. E. (2012). Normalización de Bases de Datos

Relacionales. Eae Editorial Academia Española.