Normalizacion II

4FN, 5FN

• Cuarta Forma Normal (4FN)

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X→→Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.

Ocurre esta forma normal cuando una tabla está en forma normal de Boyce Codd y toda dependencia multivaluada es una dependencia funcional.

Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si ocurre X->>Y|Z (Y y Z tienen dependencia multivaluada sobre X), entonces las tablas X,Y y X,Z reproducen sin perder información lo que poseía la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN

• Quinta Forma Normal (5FN)

Una tabla se encuentra en 5FN si: • La tabla esta en 4FN • No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que esta en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.

Es la más compleja y polémica de todas. Polémica pues no está claro en muchas ocasiones que sea una solución mejor que el no llegar a este nivel de normalización. Fue definida también por Fagin.

Es raro encontrarse este tipo de problemas cuando la normalización llega a 4FN. Se deben a restricciones muy concretas.

Normalizacion I

La normalización o estandarización es la redacción y aprobación de normas que se establecen para garantizar el acoplamiento de elementos construidos independientemente, así como garantizar el repuesto en caso de ser necesario, garantizar la calidad de los elementos fabricados, la seguridad de funcionamiento y trabajar con responsabilidad social.

La normalización es el proceso de elaborar, aplicar y mejorar las normas que se aplican a distintas actividades científicas, industriales o económicas con el fin de ordenarlas y mejorarlas. La asociación estadounidense para pruebas de materiales (ASTM) define la normalización como el proceso de formular y aplicar reglas para una aproximación ordenada a una actividad específica para el beneficio y con la cooperación de todos los involucrados.

Según la ISO (International Organization for Standarization) la normalización es la actividad que tiene por objeto establecer, ante problemas reales o potenciales, disposiciones destinadas a usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo en un contexto dado, que puede ser tecnológico, político o económico.

La normalización persigue fundamentalmente tres objetivos:

Simplificación: se trata de reducir los modelos para quedarse únicamente con los más necesarios.

Unificación: para permitir el intercambio a nivel internacional.

Especificación: se persigue evitar errores de identificación creando un lenguaje claro y preciso.

Las elevadas sumas de dinero que los países desarrollados invierten en los organismos normalizadores, tanto nacionales como internacionales, es una prueba de la importancia que se da a la normalización.

Teoría de Normalizacion

El Diccionario de Datos

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.

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.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.

1FN, 2FN, 3FN

• Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.

En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.

• Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.

• Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.

En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.

Modelo de Datos E/R

Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un modelo de datos permite describir:

Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.

Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.

Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.

Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.

Una clasificación de los modelos de datos

Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstracción que presentan:

• Modelos de Datos Conceptuales

Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.

• Modelos de Datos Lógicos

Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).

• Modelos de Datos Físicos

Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.

Atributos y Dominios

1.Atributos

1.1 Definición

En bases de datos, un atributo representa una propiedad de interés de una entidad.

Los atributos se describen en la estructura de la base de datos empleando un modelo de datos.

Por ejemplo, se podría tener una entidad llamada "Alumno". Esta entidad puede estar constituida por uno o más atributos, que son propiedades de la entidad "Alumno" que interesan para almacenarse en la base de datos. Por ejemplo, la entidad "Alumno" podría tener los atributos: nombre, apellido, año de nacimiento, etc.

La elección de los atributos de una entidad depende del uso que se le dará a la base de datos. El alumno puede tener una "religión", pero si no interesa al fin de la base de datos, no es necesario almacenarla en un atributo.

En SQL un atributo es llamado columna.

1.2 Características

Cada atributo de una relación se caracteriza por un nombre y por un dominio. El dominio indica qué valores pueden ser asumidos por una columna de la relación. A menudo un dominio se define a través de la declaración de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero también es posible definir dominios más complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacion "Personas" podemos definir un dominio por el cual los únicos valores válidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren válidas sólo las fechas de nacimiento después del uno de enero de 1960, si en nuestra base de datos no está previsto que haya personas con fecha de nacimiento anterior a esa.

2.Dominios

2.1 Definición

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".

Distintos tipos de dominios son: enteros, cadenas de texto, fecha,no procedurales etc.

2.2 Características

Característica fundamental de los dominios de una base de datos relacional es que sean "atómicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios más simples. Más formalmente se dice que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una característica de las personas en nuestra base de datos fuese la de tener uno o más hijos, no sería posible escribir la relación Personas de la siguiente manera:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)

Teoría de Relaciones II

1.Recursivas

En las bases de datos relacionales, cuando una tabla se relaciona consigo misma, este tipo de relación recibe el nombre de relación recursiva. Por ejemplo, en una relación supervisor-supervisado, una tabla que almacena los registros de empleados se relaciona consigo misma. En este caso, la tabla de empleados desempeña una función de supervisor en uno de los lados de la relación y una función de supervisado en el otro lado.

Los esquemas de asignación pueden incluir relaciones recursivas donde un elemento y su antecesor son del mismo tipo.

2.Entidades Asociativas

La entidad que resulta de considerar una interrelación entre entidades como si fuese una entidad es una entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que se define.

La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.

Ejemplo:

Recorrido es una interrelación de conectividad M:N que registra las ciudades por donde han pasado los diferentes viajes organizados por una empresa de reparto de paquetes. Consideramos recorrido una entidad asociativa con el fin de interrelacionarla con la entidad cliente; de este modo nos será posible reflejar por orden de qué clientes se han hecho repartos en una ciudad del recorrido de un viaje, así como el número de paquetes cargados y descargados siguiendo sus indicaciones.

El mecanismo de las entidades asociativas subsume el de las entidades débiles

y resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil podremos sustituirla por una entidad asociativa, pero no al revés.

Ejemplo de sustitución de una entidad débil por una asociativa:

3.Dependencias Funcionales

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento es a Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstrong:

1.Dependencia funcional Reflexiva

Si "x" está incluido en "x" entonces x es a x A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.

2.Dependencia funcional Aumentativa

X es a Y entonces XZ es a YZ

DNI es a nombre

DNI,dirección es a nombre,dirección

Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.

3.Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simbólicamente sería:

X es a Y es a Z entonces X es a Z

FechaDeNacimiento es a Edad

Edad es a Conducir

FechaDeNacimiento es a Edad es a Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).

Teoría de Relaciones I

CARDINALIDAD

Relación o Asociación

• Expresa una asociación entre ocurrencias deentidad

• Puede tener atributos propios

• Grado: número de entidades que asocia

• Cardinalidad:

Número de ocurrencias de una entidad que puedenasociarse con otra entidad

– Máxima - 1:1, 1:N, N:1, N:M

– Mínima - 0:0, 1:0, 0:1, 1:1

TIPOS DE RElaCIONES

Existen 3 tipos de relaciones:

1. De Uno a Uno

2. De Uno a Varios

3. De Varios a Varios

Diagrama E/R(Entidad/Relacion) III

MODELO FÍSICO

El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como:

Conocimiento a fondo de los tipos de objetos (elementos) soportados

Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de datos, etc

Detalles y variaciones de las versiones

Parámetros de configuración

Data Definition Language (DDL)

Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que las entidades pasen a ser tablas (más las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas.

Físicamente esta metáfora de una tabla se mapea al medio físico, con algunas consideraciones como se menciona en las siguientes secciones.

1. Atributos

1.1 Tipos de Datos

Revisar los tipos de datos disponibles en el DBMS, en especial

Número de dígitos en números enteros

La precisión de los flotantes

Cadenas de caracteres de longitud fija (char(50)) y variable (varchar(50))

Blobs (Binary large objects) y Clobs (Character large objects)

1.2 Llaves primarias

En ocasiones se pueden presentar casos en donde la llave primaria no puede representarse en alguno de los tipos ofrecidos por el dbms, en ese caso se podria definir alguno y bien optar por otra llave primaria.

Importante:

Algunos dbms poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automáticamentemanipular algun atributo para generar llaves incrementales. Pero es importante verificar: como se manejan internamente ?, se pueden reiniciar ?, se permite especificar algun valor inicial ?.

1.3 Orden de las atributos (columnas)

Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:

Columnas de longitud fija que no se actualizan frecuentemente.

Aquellas que nunca se actualizan que por lo general tendrán longitud variable.

Las que se actualizan frecuentemente.

1.4 Integridad Referencial

En la medida de lo posible indicar cuales columnas brindan o sirven de vínculo entre 2 tablas.

El usuario (programador) puede hacerse cargo de esto pero es mejor que el dbms se haga cargo.

No se recomienda en ambientes de desarrollo.

Modelo E/R(Entidad/Relación) II

MODELO LÓGICO

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.

Metodología de diseño lógico en el modelo relacional

La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.

1. Construir y validar los esquemas lógicos locales para cada vista de usuario.

2. Convertir los esquemas conceptuales locales en esquemas lógicos locales.

3. Derivar un conjunto de relaciones (tablas) para cada esquema lógico local.

4. Validar cada esquema mediante la normalización.

5. Validar cada esquema frente a las transacciones del usuario.

6. Dibujar el diagrama entidad-relación.

7. Definir las restricciones de integridad.

7. Revisar cada esquema lógico local con el usuario correspondiente.

8. Construir y validar el esquema lógico global.

9. Mezclar los esquemas lógicos locales en un esquema lógico global.

10. Validar el esquema lógico global.

11. Estudiar el crecimiento futuro.

12. Dibujar el diagrama entidad-relación final.

13. Revisar el esquema lógico global con los usuarios.

En la primera fase, se construyen los esquemas lógicos locales para cada vista de usuario y se validan. En esta fase se refinan los esquemas conceptuales creados durante el diseño conceptual,

eliminando las estructuras de datos que no se pueden implementar de manera directa sobre el modelo que soporta el SGBD, en el caso que nos ocupa, el modelo relacional. Una vez hecho esto, se obtiene un primer esquema lógico que se valida mediante la normalización y frente a las transacciones que el sistema debe llevar a cabo, tal y como se refleja en las especificaciones de

requisitos de usuario. El esquema lógico ya validado se puede utilizar como base para el desarrollo de prototipos. Una vez finalizada esta fase, se dispone de un esquema lógico para cada

vista de usuario que es correcto, comprensible y sin ambigüedad

Modelo E/R (Entidad/Relación) I

1. Modelo Conceptual

El modelo de datos entidad-relación está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre esos objetos.

Entidad

Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.

Algunos Ejemplos:

• Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
• Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de bastidor).
• Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).

Una entidad puede ser un objeto con existencia física como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta).

Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la entidad Persona puede llevar consigo las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento, etc...

Atributos

Los atributos son las características que definen o identifican a una entidad. Estas pueden ser muchas, y el diseñador solo utiliza o implementa las que considere más relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.

En un conjunto de entidades, cada entidad tiene valores específicos asignados para cada uno de sus atributos, de esta forma, es posible su identificación unívoca.

Ejemplos:

A la colección de entidades «alumnos», con el siguiente conjunto de atributos en común, (id, nombre, edad, semestre), pertenecen las entidades:

• (1, Sofía, 38 años, 2)
• (2, Josefa, 19 años, 5)
• (3, Carlos, 20 años, 2)

Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.

En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su número de id.

Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que será almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, números, solo dos letras, solo números mayores que cero, solo números enteros...).

Cuando algún atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.

Relación

Describe cierta dependencia entre entidades o permite la asociación de las mismas.

Ejemplo:  Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que la  habitación 502 se encuentra ocupada por el huésped de nombre Mark. 

Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, un huésped (entidad), se aloja (relación) en una habitación (entidad).

Conjunto de relaciones

Consiste en una colección, o conjunto, de relaciones de la misma naturaleza.

Ejemplo:

Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de la forma habitación-huésped, permiten obtener la información de los huéspedes y sus respectivas habitaciones.

La dependencia o asociación entre los conjuntos de entidades es llamada participación. En el ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped" participan en el conjunto de relaciones habitación-huésped.

Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relación.

Tipos de Estructuras

La estructura de una base de datos hace referencia a los tipos de datos, los vínculos o relaciones y las restricciones que deben cumplir esos datos (integridad de datos y redundancia de datos).

La estructura de una base de datos es diseñada o descripta empleando algún tipo de modelo de datos.

Un ejemplo a modo de descripción de la estructura de una base de datos puede ser:

ALUMNO: numero de alumnno (entero de 6 números), nombre (cadena de 30 caracteres), apellido (cadena de 30 caracteres), año de nacimiento (entero de 4 números), especialidad (entero de 3 números).

ESPECIALIDAD: numero de especialidad (entero de 3 números), nombre de especialidad (cadena de 30 caracteres).

Otro ejemplo de una estructura de base de datos

En el siguiente ejemplo mostramos una tabla “comentarios” que contiene 4 campos.

Los datos quedarían organizados como mostramos en siguiente ejemplo:

Archivos

1. Sistema de Archivos

Un sistema de gestión de archivos es aquel sistema software que provee servicios a los usuarios y aplicaciones en el uso de archivos. El único camino que tiene el usuario o la aplicación tiene para acceder a los archivos es a través de un sistema de gestión de archivos. Esto revela para el usuario o programador la necesidad de desarrollar software de propósito especial para cada aplicación y provee al sistema un medio de controlar su ventaja más importante.

Estos son los objetivos de un sistema de gestión de archivos:

1.Cumplir con las necesidades de gestión de datos y con los requisitos del usuario, que incluye el almacenamiento de, datos y la capacidad de ejecutar las operaciones en la lista precedente.

2.Garantizar, en la medida de lo posible, que el dato en el archivo es valido.

3.Optimizar el rendimiento, ambos desde el punto de vista del sistema en términos de productividad global, y como punto de vista del usuario en tiempos de respuesta.

4.Para proveer soporte de E/S para una variedad de tipos de dispositivos de almacenamiento.

5.Para minimizar o eliminar la posibilidad de perdida o destrucción de datos.

6.Para proveer un conjunto estándar de rutinas de E/S.

7.Para proveer soporte de E/S para múltiples usuarios, en caso de sistemas multiusuarios.

2. Tipos de Archivos

Los archivos pueden clasificarse en cuatro tipos básicos; que son: los archivos maestros, los archivos de transacciones, los archivos de control y los archivos de planeamiento. Esta clasificación dependerá de la relación lógica que tengan que tener los datos, para dar apoyo a la actividad de la organización.

ARCHIVO MAESTRO

Un archivo maestro es un conjunto de registros que se refieren a algún aspecto importante de las actividades de una organización, como por ejemplo el archivo de vendedores. Un archivo maestro también puede reflejar la historia de los eventos que afectan a una entidad determinada, como es en el caso de un archivo histórico de ventas. Otros ejemplos son los archivos maestros de: plan de cuentas, bancos, nomina del personal, clientes, vendedores, productos, proveedores, competidores..

ARCHIVO DE TRANSACCIONES.

Un archivo de transacciones es un archivo temporal que persigue básicamente dos propósitos; uno es el de acumular datos de eventos en el momento que ocurran, y el segundo propósito es el de actualizar los archivos maestros para reflejar los resultados de las transacciones actuales. En otras palabras, guardan información sobre los eventos que afectan a la organización y sobre los cuales se calculan datos; como es en el caso de los archivos de ventas, ordenes de producción o pago de salarios. Otros ejemplos de archivos de transacciones son los archivos de: registros contables, costos, facturas, pagos a recibir, procesos de exportación, consulta de clientes, pedidos de clientes,y pedidos de proveedores.

ARCHIVOS DE CONTROL.

Los archivos de control contienen datos de los archivos maestros y de transacciones, para permitir el análisis del desempeño de la organización. Estos archivosgeneran medidas de control de los negocios, como ser el volumen de venta por producto, volumen de venta por vendedor, volumen de venta por cliente, compras por proveedor, costo de reposición.

ARCHIVO DE PLANEAMIENTO.

Los archivos de planeamiento, contienen datos referentes a los niveles esperados de los datos existentes en los archivos maestros y de transacciones; como por ejemplo: programa de ventas, programa de compras, programa de producción, presupuesto financiero. Por lo tanto los datos existentes en un archivo de planeamiento provienen de los archivos maestros, de transacciones, y de control.

Conceptos Generales

1. TERMINOLOGÍAS
-Tablas:se refiere al tipo de modelado de datos, donde se guardan los datos recogidos por un programa. Su estructura general se asemeja a la vista general de un programa de Hoja de cálculo.
-Campos:es la mínima unidad de información a la que se puede acceder; un campo o un conjunto de ellos forman un registro
-Registro:un registro (también llamado fila o tupla) representa un objeto único de datos implícitamente estructurados en una tabla.
-Entidad/Relacion: es una herramienta para el modelado de datos de un sistema de información, estos modelos expresan entidades relevantes para un sistema de información así como sus interrelaciones y propiedades.

2. MODELO DE DATOS

Es una colección de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semántica asociada a los datos y restricciones de consistencia.

Los modelos de datos se dividen en tres grupos:

Modelos lógicos basados en objetos.
Modelos lógicos basados en registros.
Modelos físicos de datos.

-Modelos Lógicos basados en objetos
Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícita mente.

-Modelos Lógicos basados en registros

Se utilizan para describir datos en los niveles conceptual y físico.
Estos modelos utilizan registros e instancias para representar la realidad, así como las relaciones que existen entre estos registros (ligas) o apuntadores.

-Modelos Físicos
Se usan para describir a los datos en el nivel más bajo, aunque existen muy pocos modelos de este tipo, básicamente capturan aspectos de la implementación de los sistemas de base de datos.

3. BASE DE DATOS

Una base de datos o banco de datos (en ocasiones abreviada con la sigla BD o con la abreviatura b. d.) es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta

Ventajas de una base de datos

Independencia de datos y tratamiento.

Cambio en datos no implica cambio en programas y viceversa (Menor coste de mantenimiento).

Coherencia de resultados.

Reduce redundancia :

-Acciones logicamente unicas.

-Se evita inconsistencia.

Mejora en la disponibilidad de datos

No hay dueño de datos (No igual a ser públicos).

Guardamos descripción (Idea de catalogos).

Cumplimiento de ciertas normas.

Restricciones de seguridad.

Accesos (Usuarios a datos).

Operaciones (Operaciones sobre datos).

4. DBMS

El DBMS : es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos, esta compuesto por:

DDL: Lenguaje de Definición de Datos

DML: Lenguaje de Manipulación de Datos

SQL: Lenguaje de Consulta.

Explicar la diferencia entre un DBMS y una base de datos

La base de datos es una colección de archivos interrelacionados almacenados en conjunto sin redundancia y la DBMS es un conjunto de numerosas rutinas de software interrelacionadas cada una de ellas es responsable de una determinada tarea.