Las Reglas De Codd 69444l
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3i3n4
Overview 26281t
& View Las Reglas De Codd as PDF for free.
More details 6y5l6z
- Words: 1,795
- Pages: 15
Universidad Nueva Esparta Carrera: Computación Materia: Base de Datos I Profesor: José Santiago Ochoa Semestre: 4, Sección: 1004-U
LAS REGLAS DE CODD
Integrantes: Armando Stanchieri CI 20.490.736
LAS REGLAS DE CODD
Aparecer Numerosos SGBD que se anunciaban como “relacionales”. Sin embargo estos sistemas carecían de muchas características que se consideran importantes en un sistema relacional, perdiendo muchas ventajas del
modelo
relacional. Publico 12 reglas que un verdadero un sistema relacional debería cumplir de cumplir. En la práctica algunas de ellas son difíciles de realizar.
REGLA 0 Un sistema de gestión de bases de datos relaciones, debe usar exclusivamente
sus capacidades
relaciones
para
gestionar la base de datos.
REGLA 1: REGLA DE LA INFORMACION La
información en
una
base
de
datos relacionales
se
representa explícitamente en el nivel lógico exactamente de una manera
con valores en tablas.
Representan exactamente igual que los datos de .
El lenguaje de SQL para acceder a los datos de la (regla 4) Un valor posible es
el
valor nulo.
Valor desconocido Valor no aplícate
REGLA 2: REGLA DEL GARANTIZADO Cada
uno de los datos valores atómicos
de una BDR se
garantiza que son accesibles a nivel lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna.
Un dato
almacenado
en
una BDR tiene que
poder ser direccionado unívocamente.
Para ello
hay que indicar en qué tabla está, cual es la fila mediante la clave primaria) El concepto soportado
de en
la clave
primaria,
que no es
muchas implementaciones.
En
estos
casos,
para lograr
un efecto similar se
puede hacer lo siguiente:
Los atributos claves primarias no puede ser nulos (NOT NULL)
Sobre la clave primaria
No puede eliminar nunca más.
REGLA 3: TRATAMIENTO SISTEMÁTICO DE VALORES NULOS Los valores nulos son distintos de la cadena vacía, blancos, 0,1,etc
se soportan en los SGBD totalmente
relacionales para representar información desconocida o no aplicable de manera sistemática, independientemente del tipo de datos.
La
necesidad
de
los
valores
nulos
para
un
tratamiento sistemático de los menores.
Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las operaciones lógicas.
Es una posible solución existen tres (no dos) , valores
de
verdad:
Verdadero,
Falso
y
Desconocido (null). Se crean tablas de tablas para las operaciones lógicas: Por ejemplo NULL Y NULL = NULL VERDADERO Y NULL = NULL
FALSO Y NULL = FALSO VERDADERO
O
NULL = VERDADERO
HAY MUCHAS COSAS Al el manejo de los lenguajes relaciones se complica pues es más difícil de entender.
REGLA 4: CATÁLOGO DINÁMICO EN LÍNEA EN EL MODELO RELACIONAL Se representa a nivel lógico de la misma manera que los datos normales, de modo que los s autorizados pueden aplicar el mismo relacional a su consulta, igual a los datos normales.
Una consecuencia de la regla 1 por su importancia.
que se destaca
Se almacenan usando el
modelo relacional, con todas las consecuencias.
REGLA 5: REGLA DEL SUBLENGUAJE DE DATOS COMPLETO Un
sistema
relacional
debe
soportar
varios
lenguajes y varios modos de uso de terminal. Sin embargo debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:
Definición de datos.
Definición de visitas. Limitantes de integridad. Limitantes de transacción por ejemplo ( Iniciar, realizar) (Begin, commit). Manipulación de datos. Poder tener interfaces
más amigables para hacer
consultas, etc. Siempre debe haber una manera de hacerlo de manera textual, que es tanto como decir que
pueda
ser
incorporada
en
un
programa
tradicional. Un lenguaje que cumple esto en gran medida es SQL. REGLA 6: REGLA DE ACTUALIZACION DE VISTAS Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema.
El problema
es determinar cuáles son las vistas
teóricamente actualizables, ya que no está
muy
claro. Hacer unas suposiciones
particulares
sobre
las
vistas que son actualizables.
REGLA 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL Una
relación
base
o
derivada
como
un
solo
operando aplica no sólo a la recuperación de los datos (consultas), si
no también a la inserción ,
actualización y borrado de datos. El lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos). Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de datos de una en una (un registro de cada vez).
REGLA 8: INDEPENDENCIA FÍSICA DE DATOS Las aplicaciones y actividades del terminal permanecen inalteradas a nivel lógico cuandoquiera que se realicen cambios
en
las
representaciones
de
almacenamiento
o
métodos de .
El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.
REGLA 9: INDEPENDENCIA LÓGICA DE DATOS Las
aplicaciones
y
actividades
del
terminal
permanecen inalteradas a nivel lógico cualquiera que se realicen a las tablas base que preserven la información.
Modifica
el
esquema
información no valdría
lógico
preservando
por ejemplo eliminar un
atributo no es un necesario modificar nada en niveles superiores. Ejemplos de cambios que preservan la información
Un añadir de atributo a una tabla base.
Dos tablas base por la unión de las mismas. Usando vistas
de
la
unión
puedo
recrear
las
tablas
anteriores.
REGLA 10: INDEPENDENCIA DE INTERGRIDAD El integridad específicos para una determinada base de datos relacional deben poder ser definidos en el su lenguaje de datos relacional, y almacenables en el catálogo, no en los programas de aplicación.
Las bases de datos no es sólo almacenar los datos, si no
también sus relaciones y evitar que estas
(limitantes) se codifiquen en los
programas. Por
tanto en una BDR se deben poder definir limitantes de integridad.
Un ampliando más los tipos de limitantes de integridad que se pueden utilizar en los SGBDR, hasta hace poco eran muy escasos.
Una parte de los limitaciones inherentes al modelo relacional.
Una BDR tiene integridad de entidad.
Es decir,
toda tabla debe tener una clave primaria. Una BDR tiene integridad referencial. toda clave externa no nula
Es decir,
debe existir en la
relación donde es primaria.
REGLA 11: INDEPENDENCIA DE DISTRIBUCIÓN Una BDR tiene independencia de distribución. Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en una distribuida. Las BDR son fácilmente distribuibles: Se parten las tablas en fragmentos que se distribuyen. Cuando se necesitan las tablas completas se recombinan usando operaciones relacionales con los fragmentos. Sin embargo se complica más la gestión interna de la integridad, etc. Esta
regla
es
responsable
transparencia de distribución:
de
tres
tipos
de
Transparencia de localización: El tiene la impresión de que trabaja con una BD local. (aspecto de la regla de independencia física) Transparencia de fragmentación: El no se da cuenta
de
que
la
relación
con
que
trabaja
está
fragmentada. (aspecto de la regla de independencia lógica de datos). Transparencia de replicación: El no se da cuenta de que pueden existir copias (réplicas) de una misma relación en diferentes lugares. REGLA 12: REGLA DE LA NO SUBVERSIÓN Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes relacionales de más alto nivel (una relación (conjunto de registros) de cada vez). Algunos
problemas
no
se
pueden
directamente con el lenguaje de alto nivel.
solucionar
Normalmente se usa SQL inmerso en un lenguaje anfitrión para solucionar estos problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas de una relación. En cualquier caso no debe ser posible saltarse los limitantes de integridad impuestos al tratar las tuplas a ese nivel.
Edgar F. Codd (1923-2003) Edgar Frank Codd nació en Portland Bill, un remoto pueblo de Dorset, Inglaterra, hijo de un curtidor y una profesora, siendo el menor de siete hermanos. Estudió becado matemáticas y química en Oxford. Aunque podría haber evitado participar en la segunda guerra mundial por ser estudiante, se alistó en la Real Fuerza Aérea. A los 25 años viajó a los Estados Unidos y consiguió trabajo en IBM como programador matemático usando un prototipo de computador que ocupaba dos pisos completos de un edificio de oficinas en Manhattan. En 1953 emigró a Ottawa, Canadá, frustrado por la política McCarthy de persecución a los comunistas. Unos años más tarde volvió a Estados Unidos y obtuvó la ciudadanía, aunque nunca perdió su acento británico. En 1965 terminó un doctorado en computación de la Univ. de Michigan en Ann Arbor. Una
evaluación negativa de su supervisor en Nueva York significó un traslado a los laboratorios de IBM en San José en 1967. Sería aquí que Codd conocería el mundo de las bases de datos, al que se dedicaría en los años siguientes. En 1978 Codd se divorció de su primera esposa, Elizabeth. En 1981 obtuvó el premio Turing de la ACM, el más importante en computación. La vida de Codd cambió en 1983, cuando sufrió una seria caída. Luego de recuperarse, jubiló de IBM y abandonó su diversión favorita: volar. Sin embargo siguió trabajando hasta 1999, en la consultora que formó con Chris Date y Sharon Weinberg, dos ex colaboradores de IBM. Sharon, después de doce años de cortejo, pasaría a ser su segunda esposa en 1990. En 1996 obtuvó el premio de la IEEE a pioneros de la computación. Los últimos años vivió en Williams Island, Florida. Codd tuvó cuatro hijos y tenía seis nietos. Sus Contribuciones En 1969 Edgar Codd inventó el modelo relacional, el modelo de bases de datos más usado hoy en día y para muchas personas, el único que conocen. Desde el sistema R de IBM a Oracle han pasado 30 años y aún es el modelo dominante. Inicialmente el apoyo de IBM a los sistemas de bases de datos tradicionales (de redes) era mayoritario, poderoso y agresivo. Sólo años más tarde, en 1978, durante una reunión técnica de alto nivel el modelo
relacional llamó la atención del presidente de IBM, Frank Cary. Más tarde IBM anunció SQL/DS, su primer producto relacional comercial en 1981, seguido de DB2 en 1983. Sin embargo esta tardanza en adoptar el modelo relacional significó perder un mercado que tomaron otros. El trabajo inicial de Codd fue publicado en Communications of the ACM en 1970. Su trabajo sobre normalización de bases de datos fue publicado como un informe técnico de IBM en 1971. Ocho años más tarde, en ACM Transactions of Database Systems, publicó varias extensiones al modelo relacional. En 1985 postuló una lista de 13 reglas que debía cumplir un producto de bases de datos para ser llamado relacional.
LAS REGLAS DE CODD
Integrantes: Armando Stanchieri CI 20.490.736
LAS REGLAS DE CODD
Aparecer Numerosos SGBD que se anunciaban como “relacionales”. Sin embargo estos sistemas carecían de muchas características que se consideran importantes en un sistema relacional, perdiendo muchas ventajas del
modelo
relacional. Publico 12 reglas que un verdadero un sistema relacional debería cumplir de cumplir. En la práctica algunas de ellas son difíciles de realizar.
REGLA 0 Un sistema de gestión de bases de datos relaciones, debe usar exclusivamente
sus capacidades
relaciones
para
gestionar la base de datos.
REGLA 1: REGLA DE LA INFORMACION La
información en
una
base
de
datos relacionales
se
representa explícitamente en el nivel lógico exactamente de una manera
con valores en tablas.
Representan exactamente igual que los datos de .
El lenguaje de SQL para acceder a los datos de la (regla 4) Un valor posible es
el
valor nulo.
Valor desconocido Valor no aplícate
REGLA 2: REGLA DEL GARANTIZADO Cada
uno de los datos valores atómicos
de una BDR se
garantiza que son accesibles a nivel lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna.
Un dato
almacenado
en
una BDR tiene que
poder ser direccionado unívocamente.
Para ello
hay que indicar en qué tabla está, cual es la fila mediante la clave primaria) El concepto soportado
de en
la clave
primaria,
que no es
muchas implementaciones.
En
estos
casos,
para lograr
un efecto similar se
puede hacer lo siguiente:
Los atributos claves primarias no puede ser nulos (NOT NULL)
Sobre la clave primaria
No puede eliminar nunca más.
REGLA 3: TRATAMIENTO SISTEMÁTICO DE VALORES NULOS Los valores nulos son distintos de la cadena vacía, blancos, 0,1,etc
se soportan en los SGBD totalmente
relacionales para representar información desconocida o no aplicable de manera sistemática, independientemente del tipo de datos.
La
necesidad
de
los
valores
nulos
para
un
tratamiento sistemático de los menores.
Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las operaciones lógicas.
Es una posible solución existen tres (no dos) , valores
de
verdad:
Verdadero,
Falso
y
Desconocido (null). Se crean tablas de tablas para las operaciones lógicas: Por ejemplo NULL Y NULL = NULL VERDADERO Y NULL = NULL
FALSO Y NULL = FALSO VERDADERO
O
NULL = VERDADERO
HAY MUCHAS COSAS Al el manejo de los lenguajes relaciones se complica pues es más difícil de entender.
REGLA 4: CATÁLOGO DINÁMICO EN LÍNEA EN EL MODELO RELACIONAL Se representa a nivel lógico de la misma manera que los datos normales, de modo que los s autorizados pueden aplicar el mismo relacional a su consulta, igual a los datos normales.
Una consecuencia de la regla 1 por su importancia.
que se destaca
Se almacenan usando el
modelo relacional, con todas las consecuencias.
REGLA 5: REGLA DEL SUBLENGUAJE DE DATOS COMPLETO Un
sistema
relacional
debe
soportar
varios
lenguajes y varios modos de uso de terminal. Sin embargo debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:
Definición de datos.
Definición de visitas. Limitantes de integridad. Limitantes de transacción por ejemplo ( Iniciar, realizar) (Begin, commit). Manipulación de datos. Poder tener interfaces
más amigables para hacer
consultas, etc. Siempre debe haber una manera de hacerlo de manera textual, que es tanto como decir que
pueda
ser
incorporada
en
un
programa
tradicional. Un lenguaje que cumple esto en gran medida es SQL. REGLA 6: REGLA DE ACTUALIZACION DE VISTAS Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema.
El problema
es determinar cuáles son las vistas
teóricamente actualizables, ya que no está
muy
claro. Hacer unas suposiciones
particulares
sobre
las
vistas que son actualizables.
REGLA 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL Una
relación
base
o
derivada
como
un
solo
operando aplica no sólo a la recuperación de los datos (consultas), si
no también a la inserción ,
actualización y borrado de datos. El lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos). Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de datos de una en una (un registro de cada vez).
REGLA 8: INDEPENDENCIA FÍSICA DE DATOS Las aplicaciones y actividades del terminal permanecen inalteradas a nivel lógico cuandoquiera que se realicen cambios
en
las
representaciones
de
almacenamiento
o
métodos de .
El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.
REGLA 9: INDEPENDENCIA LÓGICA DE DATOS Las
aplicaciones
y
actividades
del
terminal
permanecen inalteradas a nivel lógico cualquiera que se realicen a las tablas base que preserven la información.
Modifica
el
esquema
información no valdría
lógico
preservando
por ejemplo eliminar un
atributo no es un necesario modificar nada en niveles superiores. Ejemplos de cambios que preservan la información
Un añadir de atributo a una tabla base.
Dos tablas base por la unión de las mismas. Usando vistas
de
la
unión
puedo
recrear
las
tablas
anteriores.
REGLA 10: INDEPENDENCIA DE INTERGRIDAD El integridad específicos para una determinada base de datos relacional deben poder ser definidos en el su lenguaje de datos relacional, y almacenables en el catálogo, no en los programas de aplicación.
Las bases de datos no es sólo almacenar los datos, si no
también sus relaciones y evitar que estas
(limitantes) se codifiquen en los
programas. Por
tanto en una BDR se deben poder definir limitantes de integridad.
Un ampliando más los tipos de limitantes de integridad que se pueden utilizar en los SGBDR, hasta hace poco eran muy escasos.
Una parte de los limitaciones inherentes al modelo relacional.
Una BDR tiene integridad de entidad.
Es decir,
toda tabla debe tener una clave primaria. Una BDR tiene integridad referencial. toda clave externa no nula
Es decir,
debe existir en la
relación donde es primaria.
REGLA 11: INDEPENDENCIA DE DISTRIBUCIÓN Una BDR tiene independencia de distribución. Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en una distribuida. Las BDR son fácilmente distribuibles: Se parten las tablas en fragmentos que se distribuyen. Cuando se necesitan las tablas completas se recombinan usando operaciones relacionales con los fragmentos. Sin embargo se complica más la gestión interna de la integridad, etc. Esta
regla
es
responsable
transparencia de distribución:
de
tres
tipos
de
Transparencia de localización: El tiene la impresión de que trabaja con una BD local. (aspecto de la regla de independencia física) Transparencia de fragmentación: El no se da cuenta
de
que
la
relación
con
que
trabaja
está
fragmentada. (aspecto de la regla de independencia lógica de datos). Transparencia de replicación: El no se da cuenta de que pueden existir copias (réplicas) de una misma relación en diferentes lugares. REGLA 12: REGLA DE LA NO SUBVERSIÓN Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes relacionales de más alto nivel (una relación (conjunto de registros) de cada vez). Algunos
problemas
no
se
pueden
directamente con el lenguaje de alto nivel.
solucionar
Normalmente se usa SQL inmerso en un lenguaje anfitrión para solucionar estos problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas de una relación. En cualquier caso no debe ser posible saltarse los limitantes de integridad impuestos al tratar las tuplas a ese nivel.
Edgar F. Codd (1923-2003) Edgar Frank Codd nació en Portland Bill, un remoto pueblo de Dorset, Inglaterra, hijo de un curtidor y una profesora, siendo el menor de siete hermanos. Estudió becado matemáticas y química en Oxford. Aunque podría haber evitado participar en la segunda guerra mundial por ser estudiante, se alistó en la Real Fuerza Aérea. A los 25 años viajó a los Estados Unidos y consiguió trabajo en IBM como programador matemático usando un prototipo de computador que ocupaba dos pisos completos de un edificio de oficinas en Manhattan. En 1953 emigró a Ottawa, Canadá, frustrado por la política McCarthy de persecución a los comunistas. Unos años más tarde volvió a Estados Unidos y obtuvó la ciudadanía, aunque nunca perdió su acento británico. En 1965 terminó un doctorado en computación de la Univ. de Michigan en Ann Arbor. Una
evaluación negativa de su supervisor en Nueva York significó un traslado a los laboratorios de IBM en San José en 1967. Sería aquí que Codd conocería el mundo de las bases de datos, al que se dedicaría en los años siguientes. En 1978 Codd se divorció de su primera esposa, Elizabeth. En 1981 obtuvó el premio Turing de la ACM, el más importante en computación. La vida de Codd cambió en 1983, cuando sufrió una seria caída. Luego de recuperarse, jubiló de IBM y abandonó su diversión favorita: volar. Sin embargo siguió trabajando hasta 1999, en la consultora que formó con Chris Date y Sharon Weinberg, dos ex colaboradores de IBM. Sharon, después de doce años de cortejo, pasaría a ser su segunda esposa en 1990. En 1996 obtuvó el premio de la IEEE a pioneros de la computación. Los últimos años vivió en Williams Island, Florida. Codd tuvó cuatro hijos y tenía seis nietos. Sus Contribuciones En 1969 Edgar Codd inventó el modelo relacional, el modelo de bases de datos más usado hoy en día y para muchas personas, el único que conocen. Desde el sistema R de IBM a Oracle han pasado 30 años y aún es el modelo dominante. Inicialmente el apoyo de IBM a los sistemas de bases de datos tradicionales (de redes) era mayoritario, poderoso y agresivo. Sólo años más tarde, en 1978, durante una reunión técnica de alto nivel el modelo
relacional llamó la atención del presidente de IBM, Frank Cary. Más tarde IBM anunció SQL/DS, su primer producto relacional comercial en 1981, seguido de DB2 en 1983. Sin embargo esta tardanza en adoptar el modelo relacional significó perder un mercado que tomaron otros. El trabajo inicial de Codd fue publicado en Communications of the ACM en 1970. Su trabajo sobre normalización de bases de datos fue publicado como un informe técnico de IBM en 1971. Ocho años más tarde, en ACM Transactions of Database Systems, publicó varias extensiones al modelo relacional. En 1985 postuló una lista de 13 reglas que debía cumplir un producto de bases de datos para ser llamado relacional.
Related Documents 3h463d
Las Reglas De Codd 69444l
November 2019 37
Fnbc Y Reglas Codd 5x6v41
May 2021 0
Las Reglas De Cahn 13242t
December 2019 34
Las Reglas De Competencia 3w5472
May 2021 0
Las 7 Reglas De Paracelso 2z351h
December 2022 0