Doce reglas de Codd son un conjunto de trece reglas (número cero a

doce) propuesto por Edgar Frank Codd, pionero del modelo relacional

para bases de datos, diseñado para definir lo que se requiere de una base de datos

sistema de gestión con el fin de que sea considerado relacional

Codd producido estas reglas como parte de una campaña personal para evitar su visión

de la base de datos relacional de diluirse, como vendedores de bases de datos codificados en el

principios de 1980 para volver a empaquetar los productos existentes con una chapa relacional.
Regla 12 fue

especialmente diseñada para contrarrestar un posicionamiento tales.

Regla de 0:

El sistema debe calificar como relacional, como una base de datos, y como un sistema de gestión.

Para un sistema para calificar como un sistema de gestión de bases de datos relacionales (RDBMS),

que el sistema debe utilizar sus instalaciones relacionales (exclusivamente) para gestionar la base
de datos.

Regla 1: La información

Toda la información en una base de datos relacional (incluyendo tablas y columnas nombres) es

representado en un solo sentido, es decir, como un valor en una tabla.

Regla 2: El acceso garantizado

Todos los datos deben ser accesibles. Esta regla es esencialmente una reafirmación de la
fundamental

requisito para claves primarias. Se dice que cada valor escalar individual en el

base de datos debe ser lógicamente direccionable especificando el nombre de la que contiene

tabla, el nombre de la columna que contiene y el valor de clave principal de la que contiene

fila.

Regla 3: El tratamiento sistemático de valores nulos

El DBMS debe permitir que cada campo permanezca nula (o vacío). En concreto, se debe

apoyar una representación de "información que falta y la información inaplicable" que

es sistemática, distinto de todos los valores regulares (por ejemplo, "distinto de cero o

cualquier otro número ", en el caso de valores numéricos), e independiente del tipo de datos.

También se da a entender que tales representaciones deben ser manipuladas por el DBMS en una
de manera sistemática.

FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Regla 4: Catálogo de Activo en línea basado en el modelo relacional

El sistema debe ser compatible con una línea, en línea, catálogo relacional que se puede acceder a

los usuarios autorizados por medio de su lenguaje de consulta regular. Es decir, los usuarios deben
ser

acceder a la estructura de la base de datos (catálogo) usando el mismo lenguaje de consulta

que utilizan para acceder a los datos de la base de datos.

Regla 5: El sublenguaje de datos completa

El sistema debe admitir al menos una lengua relacional que

1. Tiene una sintaxis lineal

2. Se puede utilizar tanto de forma interactiva y dentro de los programas de aplicación,

Operaciones de definición de datos 3. Es compatible (incluyendo definiciones de vista), datos

operaciones de manipulación (actualizar, así como la recuperación), la seguridad y la integridad

limitaciones, y las operaciones de gestión de transacciones (begin, commit y rollback).

Regla 6: La actualización vista

Todas las vistas que son actualizables en teoría deben ser actualizables por el sistema.

Regla 7: inserción de Alto Nivel, actualizar y eliminar

El sistema debe ser compatible con set-en-un-tiempo de insertar, actualizar y eliminar los
operadores.

Esto significa que los datos pueden ser recuperados de una base de datos relacional en conjuntos
construidos

de datos de múltiples filas y / o múltiples tablas. Esta regla establece que insertan,

actualizar y eliminar las operaciones deben ser apoyados para cualquier conjunto recuperable
lugar

no sólo para una sola fila en una sola tabla.

Regla 8: independencia de datos física

Los cambios en el nivel físico (cómo se almacenan los datos, ya sea en las matrices o vinculado

listas, etc.) no deben requerir un cambio en una aplicación basada en la estructura.

REGLAS CODD'S

FAVA - Formación en Ambientes Virtuales de Aprendizaje SENA - Servicio Nacional de Aprendizaje

Regla 9: independencia de datos lógicos

Los cambios en el nivel lógico (tablas, columnas, filas, etc.) no deben requerir una

cambiar a una aplicación basada en la estructura. Independencia de datos lógica es más

difícil de lograr que la independencia de datos física.

Regla 10: independencia Integridad

Las restricciones de integridad deben especificarse por separado de los programas de aplicación y

almacenada en el catálogo. Debe ser posible cambiar tales limitaciones como y cuando

apropiado sin afectar innecesariamente las aplicaciones existentes.

Regla 11: Distribución de la independencia

La distribución de las porciones de la base de datos a varios lugares debe ser invisible para

los usuarios de la base de datos. Aplicaciones existentes deben seguir funcionando correctamente:

1. Cuando se introdujo por primera vez una versión distribuida del DBMS; y

2. Datos Cuando existente distribuidos se redistribuyen en todo el sistema.

Regla 12: El no la subversión

Si el sistema proporciona un bajo nivel de interfaz (record-en-un-tiempo), entonces esa interfaz

no puede ser utilizado para subvertir el sistema, por ejemplo, por encima de un valor relacional

o restricción de integridad.

CODD'S 12 REGLAS, recuperados 15 de agosto de 2013. Disponible en:

http://en.wikipedia.org/wiki/Codd%27s_12_ruleskipedia.org/wiki/Codd%27s_12_rules
¿Cuál es la diferencia entre sistema

Análisis y Diseño de Sistemas?

Buena pregunta. Ambos están estrechamente relacionados - de hecho, el diseño del sistema es
una parte del desarrollo del ciclo de vida del sistema (SDLC).

Primero tienes que entender lo que es un "sistema" es. Básicamente, los sistemas de información
están en todas partes. Tenga en cuenta su supermercado local - tienen un sistema que rastrea los
niveles de inventario y reordena acciones como requerido. También tienen un sistema que se
ocupa de la parte financiera de la la organización; cuánto dinero se ha hecho a partir de un día de
cotización, presupuestos de personal, etc. Estos sistemas no solo incluyen ordenadores y software.
También se incluyen las personas que utilizan el sistema y los procedimientos.

Así que en resumen, un sistema de información es un conjunto de hardware, software,

componentes de datos, humanos y de procedimiento destinadas a dar los datos correctos y la
información a la persona adecuada en el momento adecuado.

Análisis de Sistemas se refiere al proceso en el que pasan por analistas para determinar cómo una
sistema debe operar - que es determinar lo que funciona el sistema debe realizar, si es factible
para el sistema a ser desarrollado (como viabilidad financiera; hacer los beneficios del sistema
superan a los costes de desarrollo del sistema?), qué datos va a ser recogido y almacenado. En
esencia, Análisis de Sistemas se ocupa de la resolución de problemas - la creación de un sistema
que va a resolver un problema de organización.

Diseño de Sistemas es en realidad la tercera etapa del SDLC - Es el lugar donde los diseños de
análisis cómo el sistema funcionará. Los componentes físicos del sistema se definen aquí que
especifica cómo se resolvió el problema en cuestión.

Cómo hacer un Sistema de Análisis y Diseño de cualquier sistema?

Análisis de Sistemas y Diseño Bueno, en fin (SAD) es un muy riguroso y el proceso iterativo que
requiere que uno sea de mente abierta y hace suficiente espacio para contingencias a fin de que
usted está preparado para todas las eventualidades. Usted puede seguir los pasos siguientes con el
fin de diseñar un sistema como analista:

1) Definir el Planteamiento del problema: Para esta parte tendrá que llevar a cabo investigaciones
preliminares. Muchos analistas utilizan hacer un uso extensivo de modelos y realizar entrevistas,
desarrollar modelos de flujo de trabajo con el fin de entender el flujo de corriente de información,
servicios y materiales. Le ayudará a identificar las áreas problemáticas e identificar las principales
lagunas en el sistema y cuellos de botella. Usted tendrá que consultar todos, desde los empleados
de primera línea y la alta dirección. Definir la problemática áreas, algunas herramientas que usted
puede usar en este paso pueden ser: FAVA - Formación en Ambientes Virtuales de Aprendizaje
SENA - Servicio Nacional de Aprendizaje

• diagramas diagrama de flujo.

• Los cuestionarios y entrevistas.

• cuantitativo y análisis cualitativo.

Después de este paso que debe idear un marco de tiempo y utilizar una utilidad de gestión de
proyectos la elaboración del marco y las actividades de tiempo. Establecer plazos para ti mismo.

2) Con base en el paso anterior seleccione las aplicaciones que se utilizarían en el proceso dey el
tipo de sistema informático y el software necesario para automatizar / actualizarlo. Usted tendrá
que seleccionar si desea optar por comprar un fuera de la aplicación estante o personalizar un
catering aplicación de software a sus necesidades específicas.

3) Presentar su propuesta final y obtener los términos y condiciones convenidos formalmente por
su cliente. Hacer la documentación necesaria.

4) Ejecución: La etapa más difícil y crucial en el sistema

Análisis y Diseño. Usted tendrá que ayudar a los empleados y la gestión de comprender los
beneficios del sistema propuesto. Entonces usted implementará su solución y formar a los
empleados en el nuevo sistema. También tendrá que ver la documentación necesaria para la

aplicaciones, también tendrá que evaluar paso a paso cómo el proceso

está procedien do y hacer los cambios necesarios en caso de necesidad.

En el desarrollo de software, ¿cuál es la diferencia entre el análisis y el diseño?

Análisis implica medir, detallando, aclarando, y organización. El análisis es típicamente

realizado en preparación para alguna otra actividad, tal como una decisión o un diseño.

El diseño se realiza cuando se tomó la decisión de construir algo. Diseño implica

imaginando y especificando alguna creación que se ajusta a algunos requisitos.

La mejor manera de recordar la diferencia es que se puede juzgar un diseño como bueno o malo,

mientras que sólo se puede validar un análisis tan bien o mal. Por ejemplo:

• El diseño de un coche no es bueno o malo, es bueno o malo.

• El análisis del rendimiento del coche es ya sea bien o mal, nunca es bueno

o mal.

Recuperado por CARDONA, A.N.,

de: http://www.blurtit.com/q584829.html, Setp. 10/2012. 7.20 am

Desde: http://www.blurtit.com/q947872.html, septiembre / 2012. 7.30 am