TERCERA FORMA NORMAL

La regla de la Tercera Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.

Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave.

Cuando las tablas están en la Tercera Forma Normal se previenen errores de lógica cuando se insertan o borran registros. Cada columna en una tabla está identificada de manera única por la llave primaria y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.

SEGUNDA FORMA NORMAL

La regla de la Segunda Forma Normal (2FN) establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. 

Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada. 

Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales, por ejemplo:

• Puede añadir nuevas columnas a una tabla sin afectar a las demás tablas. 
• Lo mismo aplica para las otras tablas.
• Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados. 

Primera Forma Normal en Bases de Datos (1FN)

PRIMERA FORMA NORMAL

Primera Forma Normal en Bases de Datos (1FN)

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Evitar problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

La primera forma normal, requiere que los datos sean atómicos. En otras palabras, la 1FN prohíbe a un campo contener más de un valor de su dominio de columna. También exige que todas las tablas deben tener una clave primaria. Adicionalmente, indica que una tabla no debe tener atributos que acepten valores nulos.

Cuando no existe normalización, se presentan anomalías en la base de datos. Que ocasionan problemas al momento de insertar, modificar o eliminar datos. 

NORMALIZACION DE BASE DE DATOS

El proceso de normalización de bases de datos consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación almodelo relacional.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Disminuir problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

• Cada tabla debe tener su nombre único.
• No puede haber dos filas iguales. No se permiten los duplicados.
• Todos los datos en una columna deben ser del mismo tipo.
• 
  
• 

MODELO RED

Se representan por medio de colecciones de registros y las relaciones entre los datos se representan por medio de enlaces que se pueden ver como apuntadores. Los registros se organizan como colecciones de grafos dirigidos. El modelo de red es un modelo de base de datos concebido como un modo flexible de representar objetos y su relación.

El inventor original del modelo de red fue Charles Bachman, y con ello fue desarrollado en una especificación estándar publicada en 1969 por la Conferencia de Lenguajes en Sistemas de Datos (CODASYL).

 

MODELO RACIONAL

Se usa una colección de tablas para representar tanto los datos como las relaciones entre ellos. Cada tabla contiene varias columnas, y cada columna tienen un nombre único. El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos.

Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.

Su idea fundamental es el uso de relaciones. Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados tuplas. Pese a que esta es la teoría de las bases de datos relacionales creadas por Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, pensando en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o "tupla") y columnas (también llamadas "campos").

MODELO JERÁRQUICO

Es similar al modelo de redes, en el sentido en que los datos y relaciones entre los datos se representan mediante registros y enlaces. La diferencia es que en lugar de organizarse como grafos estos lo hacen como colecciones de árboles. Un modelo de datos jerárquico es un modelo de datos en el cual los datos son organizados en una estructura parecida a un árbol. La estructura permite a la información que repite y usa relaciones padre/Hijo: cada padre puede tener muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un registro específico son catalogados bajo un tipo de entidad.

En una base de datos, un tipo de entidad es el equivalente de una tabla; cada registro individual es representado como una fila y un atributo como una columna. Los tipos de entidad son relacionados el uno con el otro usando 1: Trazar un mapa de n, también conocido como relacion de uno a varios. El ejemplo más aprobado de base de datos jerárquica modela es un IMS diseñado por la IBM.

MODELO LÓGICO DE LOS DATOS

La parte esencial de la estructura de base de datos es el modelo de datos: una colección de herramientas conceptuales para describir los datos, las relaciones de datos, la semántica de los datos y las ligaduras de consistencia. Los diferentes modelos de datos que se han propuesto se clasifican en tres grupos diferentes: modelos lógicos basados en objetos, modelos lógicos basados en registros y modelos físicos.

PROTECCIÓN DE DATOS

Proteja en tiempo real las bases de datos esenciales para las empresas contra amenazas externas e internas, así como a las internas de las propias bases de datos, con soluciones que no requieran cambios de arquitectura, costoso hardware ni periodos de inactividad. Con el software de seguridad de Intel Security para bases de datos, podrá obtener una visión general de la seguridad de las bases de datos y la postura de seguridad correspondiente, adecuar todas las políticas de administración de la seguridad de las bases de datos y mantener el cumplimiento de las normativas de seguridad. Todas nuestras soluciones están integradas con la consola de administración de McAfee ePolicy Orchestrator para administrar la seguridad de las bases de datos de forma centralizada.

McAfee Data Center Security Suite for Databases

Mejore la seguridad de las bases de datos en ambientes físicos, virtuales y en la nube mediante una solución de seguridad fácil de desplegar y muy escalable. La suite incluye McAfee Database Activity Monitoring, McAfee Virtual Patching for Databases y McAfee Vulnerability Manager for Databases.

McAfee Vulnerability Manager for Databases

Podrá obtener una visibilidad completa de la postura de seguridad de las bases de datos gracias a la evaluación de riesgo detallada de más de 4700 comprobaciones de vulnerabilidades. Clasifique las amenazas para la seguridad de las bases de datos en diferentes niveles y secuencias de comandos de solución con el fin de prepararse mejor para las auditorías y cumplir las normativas.

EL ADMINISTRADOR DE LA BASE DE DATOS

Un administrador de bases de datos (también conocido como DBA, en inglés database administrator) es aquel profesional que administra las tecnologías de la información y la comunicación, siendo responsable de los aspectos técnicos, tecnológicos, científicos, inteligencia de negocios y legales de bases de datos.

Sus tareas incluyen las siguientes:

·         Implementar, dar soporte y gestionar bases de datos corporativas.

·         Crear y configurar bases de datos relacionales.

·         Ser responsables de la integridad de los datos y la disponibilidad.

·         Diseñar, desplegar y monitorizar servidores de bases de datos.

·         Diseñar la distribución de los datos y las soluciones de almacenamiento.

·         Garantizar la seguridad de las bases de datos, realizar copias de seguridad y llevar a cabo la recuperación de desastres.

EL DICCIONARIO DE RECURSOS DE INFORMACIÓN

Un diccionario de datos es un conjunto de metadatos 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.

Es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos.

Si los analistas desean conocer cuántos caracteres abarca un determinado dato o qué otros nombres recibe en distintas partes del sistema, o dónde se utiliza, encontrarán las respuestas en un diccionario de datos desarrollado en forma apropiada.

El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos de sistemas.

BASE DE DATOS DISTRIBUIDAS

 Son la que almacenan datos que pertenecen lógicamente a un sólo sistema, pero se encuentra físicamente esparcido en varios “sitios” de la red. Un sistema de base de datos distribuidos se compone de un conjunto de sitios, conectados entre sí mediante algún tipo de red de comunicaciones, en el cual:

•  Cada sitio es un sistema de base de datos en sí mismo.

•  Los sitios trabajan en conjunto si es necesario con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario.

Lenguaje de un Sistema Gestor de Bases de Datos

Una vez finalizado el diseño de una base de datos y escogido un SGBD para su implementación, el primer paso consiste en especificar el esquema conceptual y el esquema interno de la base de datos, y la correspondencia entre ambos. En muchos SGBD no se mantiene una separación estricta de niveles, por lo que el administrador de la base de datos y los diseñadores utilizan el mismo lenguaje para definir ambos esquemas, es el lenguaje de definición de datos (LDD). El SGBD posee un compilador de LDD cuya función consiste en procesar las sentencias del lenguaje para identificar las descripciones de los distintos elementos de los esquemas y almacenar la descripción del esquema en el catálogo o diccionario de datos. Se dice que el diccionario contiene metadatos: describe los objetos de la base de datos.

Cuando en un SGBD hay una clara separación entre los niveles conceptual e interno, el LDD sólo sirve para especificar el esquema conceptual. Para especificar el esquema interno se utiliza un lenguaje de definición de almacenamiento (LDA). 

Funciones de un SGBD

  Las funciones provistas por un SGBD pueden agruparse en tres clases:

• Consulta y actualización de datos
• Mantenimiento de esquemas
• Manejo de transacciones

  Consulta y Actualización

   Ésta es la clase más básica de funciones y la única que es visible "desde afuera". Consiste en un conjunto de herramientas que permite a los distintos tipos de usuarios del SGBD extraer, manipular y modifica la información almacenada en la base de datos.

   

  Mantenimiento de esquemas

   El esquema de la base de datos es la descripción de la estructura de la información almacenada en ella. Por ejemplo, para un sistema basado en tablas, el esquema puede consistir en una lista de tablas en uso, los campos que contienen, el tipo de datos de cada campo, descripciones en lenguaje natural del propósito de cada tabla y cada campo, y restricciones sobre los valores admisibles en cada campo.

  Manejo de Transacciones

   Una de las áreas principales de aplicación de los sgbd's es lo que se llama procesamiento de transacciones. Una transacción es un programa de aplicación, generalmente de duración breve, que accede y actualiza una parte también generalmente pequeña de la base de datos. Típicos ejemplos son un depósito o extracción de una cuenta bancaria, o una reservación en un vuelo, o una verificación de una tarjeta de crédito.

  

S.G.B.D

Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el almacenamiento, modificación y extracción de la información en una base de datos, además de proporcionar herramientas para añadir, borrar, modificar y analizar los datos. Los usuarios pueden acceder a la información usando herramientas específicas de interrogación y de generación de informes, o bien mediante aplicaciones al efecto.

Estos sistemas también proporcionan métodos para mantener la integridad de los datos, para administrar el acceso de usuarios a los datos y para recuperar la información si el sistema se corrompe. Permiten presentar la información de la base de datos en variados formatos. La mayoría incluyen un generador de informes. También pueden incluir un módulo gráfico que permita presentar la información con gráficos y tablas.

Hay muchos tipos distintos según cómo manejen los datos y muchos tamaños distintos de acuerdo a si operan en computadoras personales y con poca memoria o grandes sistemas que funcionan en mainframes con sistemas de almacenamiento especiales.

SISTEMA FICHEROS DE BASE DE DATOS

Es un concepto nuevo de manejo de ficheros basado en bases de datos, como sustitutivo o añadido a la estructura jerarquica. Los ficheros se identifican por sus caracteristicas, tipo, asunto, autor o meta-informacion similar. Un fichero puede ser accedido a traves de una consulta SQL este donde este.

Ejemplos:

·         BFS

·         WinFS

OBJETIVO DE DISEÑO LÓGICO DE DATOS

El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se vaya a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones. Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero no existe un modelo estándar orientado a objetos. El modelo relacional (y los modelos previos) carecen de ciertos rasgos de abstracción que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseño lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo relacional.

DISEÑO LÓGICO DE  DATOS

- Diseño conceptual: Este diseño es independiente del modelo de DDBB usado, del ordenador, del sistema gestor de bases de datos, etc… Simplemente se estudia el problema y se seleccionan los elementos del mundo real que vamos a modelar. Este diseño es al que corresponde el diagrama E/R

- Diseño lógico: Partiendo del diseño conceptual obtenido en la fase anterior, llegamos a un diseño lógico. Transformamos las entidades y relaciones obtenidas del modelo anterior en tablas. Para ello usamos la normalización.

METODOLOGÍA  ÁGILES

Hemos estado describiendo las metodologías de desarrollo de software que han ido evolucionando a lo largo del tiempo. Cabría preguntarse:

• ¿Qué nuevas metodologías se están desarrollando?,

• ¿Siguen todas las metodologías los modelos tradicionales o están

apareciendo otras posibilidades?

Algunos desarrolladores creen que las metodologías tradicionales generan demasiada burocracia y exigen demasiado esfuerzo, sobre todo para empresas de desarrollo pequeñas y en desarrollos de proyectos pequeños. Por otro lado, el mercado competitivo actual de los productos tecnológicos, no sólo exige calidad, coste e innovación, sino también rapidez y flexibilidad. En este contexto, el mercado necesita ciclos de desarrollo más cortos.

Para solucionar estos problemas se han propuesto una serie de principios y valores que aligeren la carga de las metodologías tradicionales. Con el desarrollo de estas ideas y conceptos han aparecido un nuevo tipo de metodologías que se denominan de desarrollo ágil. Sin embargo, algunos expertos consideran que el desarrollo ágil no constituye realmente una nueva metodología, sino un conjunto de recomendaciones y principios aplicables a las metodologías tradicionales para hacerlas más flexibles, rápidas y adaptables.Están  basadas fundamentalmente en metodologías orientadas a objetos, algunas de las más utilizadas son: Programación Extrema (XP), Scrum (Schwaber y Beedle 2001), o Rational  Unified Process (RUP) que por su flexibilidad puede seguir los principios de la metodología ágil. De hecho vemos que RUP se adapta a cualquier necesidad (sistemas tradicionales, sistemas con gran incertidumbre,sistemas de tiempo real, desarrollo ágil.

METODOLOGÍAS PARA SISTEMAS DE TIEMPO REAL.

Cuando viajamos en un avión sabemos que el piloto debe solicitar permisopara despegar o para conocer ruta que debe seguir, o la altura de vuelo. Todo esto se lo indica un controlador de vuelo que se ayuda de un sistema informático. ¿Qué pasaría si hay muchos aviones en vuelo que saturan el sistema informático y el controlador aéreo tiene que esperar para dar una orden a dos aviones que intentan aterrizar al mismo tiempo en el mismo aeropuerto?

Desde luego lo mejor es no estar en esos aviones.

Un sistema informático que debe captar señales (en este caso del radar y de los sistemas de comunicación de los aviones) sin perder ninguna y que debe contestar a las mismas antes de un determinado momento, es un sistema de tiempo real. En estos sistemas la velocidad de respuesta es fundamental porque el usuario, en este caso el controlador aéreo y el piloto, no pueden esperar.

EUROMÉTODO

A lo largo de esta unidad hemos visto diferentes metodologías de desarrollo de software, que las

empresas y administraciones públicas pueden utilizar en función de sus intereses y necesidades. Cada método aporta su estructura con unas particularidades determinadas. Cuando una empresa privada o un organismo público pretenden adquirir un sistema de información informático debe establecerse unabuena colaboración y relación de entendimiento entre el proveedor y el cliente.

Uno de los principales obstáculos en la consecución de este mutuo entendimiento es la variedad de metodologías de desarrollo existentes, cada una de ellas con sus conceptos y terminología propios y en general, con unvocabulario procedente de la ingeniería del software, que no siempre es fácilmente comprendido por usuarios, compradores, responsables de la contratación, etc. Ante una determinada oferta de contratación pueden acudir distintos proveedores, y cada uno de ellos, puede ofrecer un análisis realizado con una metodología distinta, lo cual dificulta la toma de decisión sobre la opción más adecuada. ¿Habría alguna solución?

Ésa fue la pregunta que se hizo la Comisión Europea, es decir, ¿es posible establecer un marco común para toda la Unión Europea de manera que clientes y desarrolladores puedan utilizar especificaciones comunes?

Con esta idea se pensó en la elaboración de un Eurométodo que en realidad no es una metodología de desarrollo de software, sino un marco con el que pueden guiarse desarrolladores y clientes tanto de empresas privadas como administraciones públicas, para adquirir sistemas de información software con garantías.

MÉTRICA

Al igual que ocurrió en otras administraciones públicas europeas, en Españasurgió la necesidad de crear una metodología de desarrollo de software común para todas las administraciones y organismos públicos.

La propuesta del Ministerio de Administraciones Públicas fue el desarrollo de la metodología Métrica para que todas las organizaciones siguiesen el mismo modelo y unificasen los criterios para aportar homogeneidad y eficiencia a las aplicaciones informáticas. El ámbito original de aplicación fue laadministración general del estado español, pero puede ser utilizada por otras administraciones o empresas privadas. La primera versión es de 1989, la segunda versión apareció en 1993 y en el año 2001 apareció la tercera versión (Métrica V3).

¿Qué objetivos persigue la última versión de Métrica? Podemos indicar que losobjetivos generales deMétrica son:

• Satisfacer las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.

• Mejorar la productividad permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.

• Facilitar la comunicación entre todos los participantes en el desarrollo teniendo en cuenta su

papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

• Facilitar la operación, mantenimiento y uso de los productos software obtenido.

• Utilizar las distintas tecnologías que actualmente están conviviendo y los aspectos de gestión que

aseguran que un proyecto cumple sus objetivos en términos de calidad, coste y plazos.

SSADM

En 1980 el gobierno británico plantea la necesidad de crear una metodología para unificar y

estandarizar los proyectos de software de las distintas administraciones. Así se desarrolló, entre el

Central Computing and  Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), la metodología SSADM (Structures Systems Analysis and Design Method).

Veamos algunas de las características fundamentales de SSADM que nos permitan acercarnos a esta metodología:

• Centrada en los usuarios, atendiendo a sus requisitos y su participación.

• Define de forma clara el proceso de producción, dando especificaciones acerca de qué hacer, cuándo y cómo.

• Utiliza tres puntos de vista, para orientarse a datos, eventos y procesos.

• Flexibilidad en herramientas y técnicas de implementación, proporcionando un conjunto de

Procedimientos para llevar a cabo las distintas tareas del análisis y diseño.

MERISE

El proyecto Merise nace en 1977 dentro del centro CTI (Centre Technique d’Information) perteneciente al Ministerio de Industria Francés. Su objetivo era desarrollar una metodología de desarrollo del software para cubrir las necesidades tanto de la empresa pública como de las empresas en general. En 1978 se presentó su primera versión para el sector público, y fue en 1982cuando el modelo se revisó y se extendió a las empresas del sector privado. Merise puede ser utilizado para el desarrollo de todo tipo de sistemas de información, desde aquellos que utilizan bases de datos hasta los que procesan eventos en tiempo real, y pretende que los proyectos se completen con éxito dentro del costo y tiempos planeados. La metodología Merise aportó un ciclo de vida más largo que los existentes anteriormente con un conjunto definido de etapas. Abarca los aspectos relacionados con:

• La recopilación y validación de la información.

• Capacitación de personal.

• Evaluación de equipos informáticos.

• Análisis, diseño y validación de los procesos.

• Implementación, gestión de costos y tiempos y el desarrollo del código.