SlideShare uma empresa Scribd logo
1 de 11
Baixar para ler offline
“Escuela Militar de Ingeniería”
                                   Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                           Ing. Osamu Yokosaki
                         INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL



Integridad y Seguridad

Introducción

Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones
hechas a la base de datos por los usuarios autorizados no provoquen la perdida de la
consistencia de los datos. Por tanto, las restricciones de integridad protegen a la base de datos
contra los daños accidentales.

Lo habitual en este sentido es limitarse a restricciones de integridad que puedan verificarse con
una sobrecarga minima, para el efecto también se puede aplicar la técnica de disparadores lo
que ayuda en la validación de la seguridad e integridad. Otro aspecto a ser considerado radica
también en la protección que se debe considerar frente a los accesos no autorizados para de
esta manera reducir o eliminar los posibles daños.

Restricciones sobre atributos

Definición de Dominio
El asociar un dominio a cada atributo restringe el conjunto de valores que puede tomar ese
atributo.

Ejemplo:
“El tipo de publicación únicamente puede ser Novela, Cuento, Teatro o Poesía”.
• Dominios:
Dom_tipo : {Novela, Cuento, Teatro, Poesía, ...}
• Publicaciones:
Publicación(id_lib:dom_id_lib, título:dom_título, tipo:dom_tipo,
autor_id:dom_autor_id);

Las restricciones de los dominios son la forma más simple de restricción de integridad. Se
especifica para cada atributo un dominio de valores posibles.
Una definición adecuada de las restricciones de los dominios no sólo permite verificar los
valores introducidos en la base de datos sino también examinar las consultas para asegurarse
de que tengan sentido las comparaciones que hagan.
Por ejemplo, normalmente no se considerará que la consulta “Hallar todos los clientes que
tengan el nombre de una sucursal” tenga sentido. Por tanto, nombre-cliente y nombre-sucursal
deben tener dominios diferentes.
La cláusula check de SQL:1999 permite restringir los dominios de maneras poderosas que no
permiten la mayor parte de los sistemas de tipos de los lenguajes de programación.
La cláusula check permite especificar un predicado que debe satisfacer cualquier valor
asignado a una variable cuyo tipo sea el dominio. Por ejemplo:
Número de cifras
Número de decimales

create domain sueldo-por-hora numeric(4,2)
constraint comprobación-valor-sueldo check(value ≥ 6.00)
Según [Korth y Silberschatz]


Restricciones de dominio

Los límites de dominios son la forma más elemental de restricciones de integridad. Son fáciles
de probar por el sistema siempre que se introduce un nuevo dato en la base de datos.
Es posible que varios atributos tengan el mismo dominio. Por ejemplo, los atributos nombre-
cliente y nombre empleado podrían tener el mismo dominio, el conjunto de todos los nombres
de personas. Sin embargo los dominios de saldo y nombre-sucursal, por supuesto, deben ser
distintos. En el nivel de implementación, los nombres de cliente y los nombres de sucursal son



                                                1
“Escuela Militar de Ingeniería”
                                   Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                            Ing. Osamu Yokosaki
                        INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

cadenas de caracteres. Podemos ver que una definición adecuada de restricciones de dominio
no sólo nos permite probar valores insertados en la base de datos sino que también nos
permite probar consultas para asegurar que la comparación que se hace tiene sentido.
Las restricciones de dominio especifican que el valor de cada atributo A debe ser un valor
atómico del dominio dom(A) para ese atributo. Los tipos de datos asociados a los dominios por
lo general incluyen los tipos de datos numéricos estándar de los números enteros (como
entero- corto, entero, entero-largo) y reales (flotante y flotante de doble precisión). También
disponemos de caracteres, cadenas de longitud fija y cadenas de longitud variable, así como
tipos de datos de fecha, hora, marca de tiempo y dinero. Otros dominios posibles se pueden
describir mediante un intervalo de valores de un tipo de datos o como un tipo de datos
enumerado en el que se listan explícitamente todos los valores posibles.

Restricción de Valores Nulos

Para determinado atributos, los valores nulos pueden ser inapropiados. Considérese una tupla
en la relación cliente la que nombre-cliente es un valor vació. Una tupla de este tipo da una
calle y una ciudad para un cliente anónimo y, por tanto, no contiene información útil. En casos
como éste, deseamos prohibir los valores nulos, restringiendo el dominio de ciudad-cliente para
que excluya los valores nulos.

El SQL estándar permite que la declaración del dominio de un atributo incluya la especificación
not null . Esto prohíbe la inserción de un valor nulo para este atributo. Cualquier modificación
de la base de datos que causara que se insertase un valor nulo en un dominio not null genera
un diagnóstico de error.

Hay muchas situaciones en las que la prohibición de valores nulos es deseable. Un caso
particular en el que es esencial prohibir los valores nulos es en la clave primaria de un
esquema de relación

Restricciones de existencia

Dentro de las restricciones de los dominios, un tipo especial de restricción que se puede aplicar
a cualquier dominio es la restricción de existencia.
Esta restricción evita la aparición de valores nulos en las columnas.

Restricción de Valor No Nulo

La definición de una restricción de valor no nulo sobre un conjunto de atributos K de la
relación R expresa la siguiente propiedad: “no debe haber en R una tupla que tenga el valor
nulo en algún atributo de K”.

Si muchos de los tributos no se aplican a todas las tuplas de la relación, se acabará con un
gran número de nulos en esas tuplas. Esto puede originar un considerable desperdicio en el
nivel de almacenamiento y posiblemente dificultar el entendimiento del significado de los
atributote y la especificación de operaciones de Reunión con en el nivel lógico. Otro problema
con los nulos es cómo manejarlos cuando se aplican funciones agregadas como COUNT o
SUM. Además, los nulos pueden tener múltiples interpretaciones, como los siguientes:

• El atributo no se aplica a esta tupla
• Se desconoce el valor del atributo para esta tupla.
• El valor se conoce pero está ausente; esto es, todavía no se ha registrado.

Tener la misma representación para todos los nulos puede hacer que se confundan los
diferentes significados que podrían tener. Por tanto, hasta donde sea posible, evite incluir en
una relación base atributos cuyos valores puedan ser nulos. Si no es posible evitar los nulos,
asegúrese de que se apliquen sólo en casos excepcionales.




                                                2
“Escuela Militar de Ingeniería”
                                   Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                            Ing. Osamu Yokosaki
                        INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

Ejemplo: VNN: { título }
“No debe haber en Publicación una tupla que tenga el valor nulo en algún atributo de título”.
Formalmente esta restricción se define como:
∀t:Publicación ( nulo(t.título))

Restricción de aserción

Una Técnica más formal para representar restricciones explícitas es con un lenguaje de
especificación de restricciones , que suele basarse en alguna variación del cálculo relacional.
Este enfoque declarativo establece una separación clara entre la base de restricciones (en
la que las restricciones se almacenan en una forma codificada apropiada) y el subsistema de
control de integridad del SGBD (que tiene acceso a la base de restricciones para aplicar
estas últimas correctamente a las transacciones afectadas).

Cuando se usa esta técnica, las restricciones suelen llamarse aserciones . Se ha sugerido el
uso de esta estrategia con SGBD relaciónales. El subsistema de control de integridad compila
las aserciones, que entonces se almacenan en el catalogo del SGBD, donde el subsistema de
control de integridad puede consultarlas e imponerlas automáticamente. Esta estrategia es muy
atractiva desde el punto de vista de los usuarios y programadores por su flexibilidad.

Según [Elmasri / Navathe ]

Las restricciones de integridad protegen la base de datos contra daños accidentales. Una base
de datos almacena información sobre alguna parte del mundo real, a la que denominamos o
universo de discurso . Ciertas reglas, las restricciones de integridad, gobiernan el minimundo.
Cuando diseñamos un esquema para una aplicación de base de datos particular, una actividad
importante consiste en identificar las restricciones de integridad que se deben cumplir en la
base de datos.

Restricciones de unicidad

La definición de una restricción de unicidad sobre un conjunto de atributos K de la relación R
expresa la siguiente propiedad: “no debe haber en R dos tuplas que tengan el mismo valor en
todos los atributos del conjunto K”.

Ejemplo: Uni: {id_lib}
“No debe haber en Publicación dos tuplas que tengan el mismo valor en el atributo id_lib”.
Formalmente esta restricción se define como:
  (∃t1:Publicación (∃t2:Publicación (t1≠t2 ∧t1.id_lib = t2.id_lib
∧ nulo(t1.id_lib) ∧ nulo( t2.id_lib))))
Otro tipo especial de restricción que se puede aplicar a cualquier dominio es la restricción de
unicidad.
Esta restricción evita la aparición de valores duplicados en las columnas.
Por ejemplo:
Sólo se admite una sucursal en cada ciudad.
CREATE TABLE Sucursales
(nombre-sucursal VARCHAR(20),
ciudad-sucursal VARCHAR(20) NOT NULL, - Restricción de existencia
PRIMARY KEY(nombre-sucursal)
UNIQUE (ciudad-sucursal)) - Restricción de unicidad
Bases de datos y sistemas de información


Clave Primaria

Las claves se usan para acceder a las tablas, y existen dos tipos: Claves primarias y Claves
foráneas. Una Clave primaria identifica unívocamente a un registro en una tabla, mientras que




                                                3
“Escuela Militar de Ingeniería”
                                     Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                           Ing. Osamu Yokosaki
                           INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

una Clave foránea accede a la información de otra tabla relacionada por medio de una Clave
primaria.


Claves Foráneas
Las claves se usan para acceder a las tablas: Claves primarias y Claves foráneas. Una Clave
primaria identifica únicamente un registro en una tabla, mientras que una Clave foránea accede
datos en alguna otra tabla relacionada por su Clave primaria.

Las claves foráneas se representan en el UML de Enterprise Architect usando operaciones
estereotipadas. Una Clave foránea es una colección de columnas (atributos) que en conjunto
tienen algún significado operacional (fuerzan una relación a una Clave primaria en otra tabla).
Una clave foránea se modela como una operación estereotipada con el estereotipo FK; los
parámetros de la operación pasan a ser las columnas involucradas en la clave.

Tenga en Cuenta: Es necesario definir una Clave foránea para acceder otra tabla a través de
su Clave primaria. Las Claves primarias son una característica de algunos sistemas de
administración de basededatos, proporcionando "extras" como verificación de integridad
referencial que previene la eliminación de un registro si su valor de clave primaria existe en
alguna otra clave foránea de la tabla. La mismas cosas se pueden obtener
programáticamente.

Para crear una clave foránea, haga clic en el vínculo.

También puede tener que definir una plantilla de nombre para las claves foráneas.


Integridad Referencial

Según [Korth y Silberschatz]

A menudo queremos asegurar que un valor que aparece en una relación para un conjunto de
atributos dado también aparece para un cierto conjunto de atributos en otra relación. Esto se
llama integridad referencial.

Las restricciones de integridad referencial se representan frecuentemente. Si obtenemos el
esquema de base de datos relacional construyendo tablas desde diagramas E-R, entonces
todas las relaciones que surgen de un conjunto de relaciones tienen restricciones de integridad
referencial. Un conjunto de relaciones n-ario R, referente a los conjunto de entidades E1, E2, …,
En. Ki representa la clave primaria de Ei. Los atributos del esquema de relaciones para el
conjunto de relaciones R incluyen K1 È K2 È … È Kn. Cada Ki del esquema de R es una clave
exterior que conduce a una restricción de integridad referencial

Según [Elmasri / Navathe]

La restricción de integridad referencial se especifica entre dos relaciones y sirve para mantener
la consistencia entre tuplas de las dos relaciones. En términos informales, la restricción de
integridad referencial establece que una tupla en una relación que haga referencia a otra
relación deberá referirse a una tupla existente en esa relación. Por ejemplo, en la fig. 3.17 el
atributo ND de EMPLEADO da el número del departamento para el cual trabaja cada
empleado; por tanto, su valor en cada tupla de EMPLEADO deberá coincidir con el valor de
NÚMEROD en alguna tupla de la relación DEPARTAMENTO.

EMPLEADO
NOMBREE                NSS         FECHAN        DIRECCIÓN                     ND
Silva, José B.         123456789   09-ENE-55     Fresnos 731, Higueras, MX     5
Vizcarra, Federico     333445555   08-DIC-45     Valle 638, Higueras, MX       5
Zapata, Alicia J.      999887777   19-JUL-58     Castillo 3321, Sucre, MX      4



                                                  4
“Escuela Militar de Ingeniería”
                                    Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                          Ing. Osamu Yokosaki
                           INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

Valdés, Jazmín S. 987654321      20-JUN-31      Bravo 291, Belén, MX         4
Nieto, Ramón K     666884444     15-SEP-52      Espiga 957, Heras, MX        5
Esparza, Josefa A. 456456456     31-JUL-62      Rosas 5631, Higueras, MX     5
Jabbar, Ahmed V. 987987987       29-MAR-59      Dalias 980, Higueras, MX     4
Botello, Jaime E. 888665555      10-NOV-27      Sorgo 450, Hogueras, MX      1


DEPARTAMENTO
                                                                     NÚMEROD      NSSGTED



NOMBRED
Investigación                                             5                       333445555
Administración                                            4                       987654321
Dirección                                                 1                       888665555
Figura 3.17. Ejemplos de relaciones EMPLEADO y DEPARTAMENTO

Resumen
A menudo queremos asegurar que un valor que aparece en una relación para un conjunto de
atributos dado también aparece para un cierto conjunto de atributos en otra relación. Esto se
llama integridad referencial.

En términos informales, la restricción de integridad referencial establece que una tupla en una
relación que haga referencia a otra relación deberá referirse a una tupla existente en esa
relación. Por ejemplo, en la fig. 3.17 el atributo ND de EMPLEADO da el número del
departamento para el cual trabaja cada empleado; por tanto, su valor en cada tupla de
EMPLEADO deberá coincidir con el valor de NÚMEROD en alguna tupla de la relación
DEPARTAMENTO.

NOMBREE            NSS           FECHAN         DIRECCIÓN                    ND
Silva, José B.     123456789     09-ENE-55      Fresnos 731, Higueras, MX    5
Vizcarra, Federico 333445555     08-DIC-45      Valle 638, Higueras, MX      5
Zapata, Alicia J.  999887777     19-JUL-58      Castillo 3321, Sucre, MX     4
Valdés, Jazmín S. 987654321      20-JUN-31      Bravo 291, Belén, MX         4
Nieto, Ramón K     666884444     15-SEP-52      Espiga 957, Heras, MX        5
Esparza, Josefa A. 456456456     31-JUL-62      Rosas 5631, Higueras, MX     5
Jabbar, Ahmed V. 987987987       29-MAR-59      Dalias 980, Higueras, MX     4
Botello, Jaime E. 888665555      10-NOV-27      Sorgo 450, Hogueras, MX      1




NOMBRED                NÚMEROD   NSSGTED
Investigación          5         333445555
Administración         4         987654321
Dirección              1         888665555

Figura 3.17. Ejemplos de relaciones EMPLEADO y DEPARTAMENTO

• Reglas de Relación

Según [Elmasri / Navathe]

• Orden de las tuplas en una relación: una relación se define como un conjunto de tuplas
matemáticamente, los elementos de un conjunto no están ordenados; por tanto, las tuplas de
una relación no tienen orden específico.




                                                 5
“Escuela Militar de Ingeniería”
                                    Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                           Ing. Osamu Yokosaki
                          INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

El ordenamiento de las tuplas no forma parte de la definición de una relación, porque la
relación intenta representar los hechos en un nivel lógico abstracto.

• Orden de los valores dentro de una tupla, y definición alternativa de relación: Una tupla es
una lista ordenada de n valores, así que el orden de los valores de una tupla y por tanto de los
atributos en la definición de un esquema de relación es importante. No obstante, en un nivel
lógico, el orden de los atributos y de sus valores en realidad no es importante en tanto se
mantengas la correspondencia entre atributos y valores.

• Valores en las Tuplas: Cada valor en una tupla es un valor atómico; esto es, no es divisible
en componentes en lo que respecta al modelo relacional. Por ello no se permiten valores
compuestos ni multivaluados.

Reglas de base de datos

Según [Elmasri / Navathe]

• Una base de datos representa algún aspecto del mundo real, en ocasiones llamado
minimundo o universo de discurso. Las modificaciones del minimundo se reflejan en la base
de datos.
• Una base de datos es un conjunto de datos lógicamente coherente, con cierto significado
inherente. Una colección aleatoria de datos no puede considerarse propiamente una base de
datos.
• Toda base de datos se diseña, construye y prueba con datos para un propósito específico.
Esta dirigida a un grupo de usuarios y tiene ciertas aplicaciones preconcebidas que interesan a
dichos usuarios.

En otras palabras, una base de datos tiene una fuente de la cual se derivan los datos, cierto
grado de interacción con los acontecimientos del mundo real y un público que está activamente
interesado en el contenido de la base de datos.

• Reglas de negocios

Según [Elmasri / Navathe]

Una base de datos almacena información sobre alguna parte del mundo real, a la que
denominamos minimundo o universo de discurso. Ciertas reglas, las restricciones de
integridad, gobiernan el minimundo, y suelen recibir el nombre de reglas de negocios. Cuando
diseñamos un esquema para una aplicación de base de datos particular, una actividad
importante consiste en identificar las restricciones de integridad que se deben cumplir en la
base de datos.

Según [ David M. Kroenke]

El último elemento de un esquema de base de datos son las reglas de negocios. Son
restricciones en las actividades de negocios que necesitan reflejarse en la base de datos y en
sus aplicaciones. Los siguientes son ejemplos de reglas de negocios para
Highline Collage:

               1. Para pedir prestado cualquier equipo, un capitán debe tener un número de
                  teléfono local.
               2. Ningún capitán puede tener prestadas a la vez más de siete pelotas de soccer.
               3. Los capitanes deben regresar todo el equipo dentro de los cinco días
                  posteriores al final de cada semestre.
               4. Ningún capitán puede pedir prestado más equipo si tiene algún material
                  vencido.




                                                 6
“Escuela Militar de Ingeniería”
                                    Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                          Ing. Osamu Yokosaki
                          INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

Las reglas de negocios son una parte importante del esquema porque especifican las
limitaciones sobre los valores de datos permitidos que deben cumplirse, sin importar la forma
en la que los cambios en los datos llegan al motor DBMS. Sin tomar en cuenta si una solicitud
no válida de un cambio de datos viene del usuario de una forma, de una solicitud de
consulta/actualización o de un programa de aplicación, el DBMS lo debe rechazar.

Los actuales productos DBMS sólo ofrecen un cumplimiento limitado de las reglas de negocios,
de modo que la mayor parte de las reglas deben cumplirse mediante programas de aplicación y
procedimientos llevados a cabo por el usuario. La situación está cambiando y se están
desarrollando productos DBMS para cumplir las reglas de negocios.


Resumen
Las reglas de negocios son restricciones en las actividades de negocios que necesitan
reflejarse en la base de datos y en sus aplicaciones. Los siguientes son ejemplos de reglas de
negocios para
Highline Collage:

               1. Para pedir prestado cualquier equipo, un capitán debe tener un número de
                  teléfono local.
               2. Ningún capitán puede tener prestadas a la vez más de siete pelotas de soccer.
               3. Los capitanes deben regresar todo el equipo dentro de los cinco días
                  posteriores al final de cada semestre.
               4. Ningún capitán puede pedir prestado más equipo si tiene algún material
                  vencido.

Las reglas de negocios son una parte importante del esquema porque especifican las
limitaciones sobre los valores de datos permitidos que deben cumplirse, sin importar la forma
en la que los cambios en los datos llegan al motor DBMS. Sin tomar en cuenta si una solicitud
no válida de un cambio de datos viene del usuario de una forma, de una solicitud de
consulta/actualización o de un programa de aplicación, el DBMS lo debe rechazar.

Restauración de la Integridad referencial

La regla de integridad referencial se enmarca en términos de estados de la base de datos: nos
dice lo qué es un estado ilegal ¡¡pero no nos dice cómo podemos evitarlo!!
¿Qué hacer si estando en un estado legal, llega una operación que conduce a un estado
ilegal? Existen dos opciones:
• Rechazar la operación.
• Aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un
estado legal.
Es tarea del diseñador de la base de datos indicar qué operaciones sedeben rechazar y cuales
requieren operaciones adicionales, u operaciones de compensación.




                                                 7
“Escuela Militar de Ingeniería”
                                  Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                        Ing. Osamu Yokosaki
                       INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL




Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?
Regla de borrado: ¿Qué hacer si se intenta borrar la tupla a la que hace referencia una clave
ajena?
• Restringir
• Propagar
• Anular
Regla de modificación: ¿Qué hacer si se intenta modificar el valor de
la clave primaria de la tupla a la que hace referencia una clave ajena?
• Restringir
• Propagar
• Anular

Diccionario de bases de datos

El diccionario de datos guarda y organiza los detalles del Diagrama de Flujo de Datos (DFD).
Es el segundo componente del análisis estructurado. También se conoce como "Data
Repository". Incluye el contenido de los data flow (flujos de datos), los "data store", las
entidades externas y los procesos.

3.6.1 Concepto
Según [David M. Kroenke]
Un diccionario de datos es una herramienta de importancia para el administrador de la base de
datos, es un catalogo accesible para el usuario de datos relacionados. Con la base de datos.

Según [Elmasri/Navathe]
Con el termino de diccionario de datos suele designarse una utilería de software más general
que un catalogo. Los sistemas de diccionario de datos sirven para mantener información
relativa al hardware y software, la documentación y los usuarios del sistema, así como otra
información pertinente para la administración del sistema.

Resumen
Los sistemas de diccionario de datos sirven para mantener información relativa al hardware y
software, la documentación y los usuarios del sistema, así como otra información pertinente
para la administración del sistema. Es un catalogo accesible para el usuario de datos
relacionados Con la base de datos.



                                               8
“Escuela Militar de Ingeniería”
                                    Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                             Ing. Osamu Yokosaki
                         INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL



3.6.2 Contenido y función
Según [Korth y Silberschatz]
El diccionario de datos almacena información acerca de la estructura de la base de datos, y la
información de autorización, y datos acerca de las relaciones.

Tipos de información que el sistema debe almacenar están:
• Los nombres de las relaciones.
• Los nombres de los atributos de cada relación.
• Los dominios de los atributos.
• Los nombres de las vistas definidas en la base de datos y la definición de esas vistas.
• Las restricciones de integridad de cada relación (por ejemplo, las restricciones e clave).

Además de esto, muchos sistemas conservan los datos siguientes de los usuarios del sistema:
• Nombres de los usuarios autorizados.
• Información contable acerca de los usuarios.

En los sistemas que utilizan estructuras altamente sofisticadas para almacenar relaciones,
pueden conservarse datos estadísticos y descriptivos acerca de las relaciones:
• Número de tuplas en cada relación.
• Método de almacenamiento utilizado para cada relación (por ejemplo, agrupado o sin
agrupar).

Tipos
Según [Elmasri/Navathe]

Diccionario de datos Activo: Es un diccionario cuyas entradas son modificadas en forma
automática por el software, siempre que ocurran modificaciones en la escritura de la base de
datos.
Diccionario de datos Pasivo: necesitan ser actualizados en forma separada, para hacer
modificaciones en la base de datos, de lo contrario no reflejarán con exactitud el estado de la
base de datos.
Los diccionarios de datos Activos cuestan más, pero aseguran se actualicen; no están
disponibles con todos los productos DBMS.
Los diccionarios de datos pasivos son menos costosos que los activos, pero se requiere de
mayor esfuerzo para mantenerlos actualizados. Cualquiera de ellos es una gran ayuda al DBA
para registrar y rastrear nombres, formatos, relaciones y referencias cruzadas de los datos.

Estructura de un Diccionario de datos (Data Dictionary)


Data elements (elementos de datos)
        Es la parte más pequeña de los datos que tiene significado en el sistema de
información. Se combinan varios elementos de datos para hacer los records o "data structures".
Ejemplo: nombre, dirección, seguro social.

Data Structure (Estructura de datos)
        También se conocen como record. Es la combinación de elementos de datos
relacionados que se incluye en un flujo de datos o se retiene en un "data store".

Documentación:

Data elements - Las características que se describen en el diccionario de datos son:

1. Name - Es el nombre del elemento de datos; debe ser significativo.
2. Alias - Cualquier otro nombre que se pueda usar para referirse al elemento de datos. Por
   ejemplo, el nombre de un elemento de datos puede ser Balance actual, y el alias puede ser
   Deuda. Solo se incluye el alias si realmente es necesario utilizarlo.



                                                 9
“Escuela Militar de Ingeniería”
                                   Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                            Ing. Osamu Yokosaki
                         INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

3. Type y Size - Type o tipo se refiere a si el elemento de datos contiene valor numérico,
    caracteres o alfabético. Size o tamaño se refiere al máximo de caracteres o de dígitos que
    puede tener el elemento de datos.
4. Output format or edit mask - Indica cómo se presenta el dato al mostrarse en pantalla o al
    imprimirse en un reporte. Por ejemplo, el número de teléfono del cliente se puede guardar
    en el disco usando solo números 7878889999, pero presentarse editado en la pantalla o en
    el reporte (787) 888-9999.
5. Default value - Es el valor que el elemento de datos tiene si no se cambia entrando otro
    valor.
6. Prompt, column header or field caption - Es el nombre que se presenta en la pantalla o el
    título del dato en el reporte.
7. Source - De dónde se origina el valor del elemento de datos. Puede ser una forma, un
    departamento, otro sistema, etc.
8. Security - Identifica los individuos o departamentos que pueden modificar el elemento de
    datos. Por ejemplo, la línea de crédito puede ser cambiada por el gerente de crédito.
9. Responsible user(s) - Identifica el (los) usuarios responsables de entrar o cambiar los
    valores del elemento de datos.
10. Acceptable Data and Data validation - Se especifica el dominio o valores permitidos.
    Pueden ser valores específicos, una lista de valores, los valores que se encuentren en otro
    archivo, etc. El valor puede tener reglas de validación; por ejemplo, el salario debe estar
    entre lo permitido para la posición que el empleado ocupa.
11. Derivation formula - Si el valor es el resultado de un cálculo, se muestra la fórmula que se
    utiliza.
12. Description or comments - Para proveer información adicional, notas o descripciones.


Data flows (Flujo de datos) - Las características que se describen en el flujo de datos son:

1.        Name – El nombre del flujo de datos tal y como aparece en el DFD.
2.        Alias – Otro nombre con que se conozca el flujo de datos.
3.        Abbreviation or ID – Código que provee acceso rápido al flujo de datos en un
     diccionario de datos automatizado.
4.        Description – Describe el flujo de datos y su propósito.
5.        Origin – De donde sale (la fuente) el flujo de datos. Puede ser un proceso, un “data
     store” o una entidad.
6.        Destination – El punto final del flujo de datos en el DFD. Puede ser un proceso, un
     “data store” o una entidad.
7.        Record – Cada flujo de datos representa un grupo de elementos de datos relacionados,
     o un record. Los records y los flujos de datos se definen por separado para que más de un
     flujo de datos o “data store” pueda hacer referencia al mismo record.
8.        Volume and frequency – Describe el número esperado de ocurrencias para el flujo de
     datos por unidad de tiempo.


“Data store” – Las características que se describen en el “data store” son:

1.        Name – El nombre del “data store” según aparece en el DFD.
2.        Alias – Otro nombre con el que se pueda llamar al “data store”.
3.        Abbreviation or ID – Código que provee un acceso rápido al “data store” en un
     diccionario de datos automatizado.
4.        Description – Describe el “data store” y su propósito.
5.        Input data flows – Los nombres de los flujos de datos que entran al “data store”.
6.        Output data flows – Los nombres de los flujos de datos que salen del “data store”.
7.        Record – El nombre del record en el diccionario de datos para el “data store”.
8.        Volume and Frequency – El número estimado de records guardados en el “data store”,
     al igual que el aumento o cambio esperado.




                                               10
“Escuela Militar de Ingeniería”
                                     Mcal. Antonio José de Sucre
Base de Datos II
Análisis de Sistemas                                                           Ing. Osamu Yokosaki
                          INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL

Proceso – Se documenta cada función primitiva. Se incluye:

1.       Process name or label – El nombre del proceso como aparece en el DFD.
2.       Purpose or description – Un resumen del propósito general del proceso. Los detalles se
     documentan en el Process Description.
3.       Process number – Número de referencia que identifica el proceso y su relación con los
     niveles del sistema.
4.       Input data flows – Los nombres de los flujos de datos que entran al proceso.
5.       Output data flows – Los nombres de los flujos de datos que salen del proceso.
6.       Process Description – Se explican los detalles del proceso.


Entidades Externas – Las características que se describen son:

1.        Name
2.        Alias
3.        Description – Describe a la entidad y su propósito.
4.        Input data flow
5.        Output data flow


Record – Se describe lo siguiente:

1.        Record name
2.        Alias
3.        Description
4.        Record content or composition – Una lista de todos los elementos de datos incluidos en
     el record. Se identifica cualquier “key” primario, o sea un elemento de datos en el record
     que identifica en forma única al record.




                                                 11

Mais conteúdo relacionado

Destaque

Reglas de integridad
Reglas de integridadReglas de integridad
Reglas de integridadMemo Wars
 
Integridad
IntegridadIntegridad
Integridad99909
 
INTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESS
INTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESSINTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESS
INTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESSitsl
 
Reglas de integridad bd relacional
Reglas de integridad bd relacionalReglas de integridad bd relacional
Reglas de integridad bd relacionalDenisse C
 
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.Erivan Martinez Ovando
 
Integridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosIntegridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosDrakonis11
 
Cómo descargar presentaciones desde SlideShare
Cómo descargar presentaciones desde SlideShareCómo descargar presentaciones desde SlideShare
Cómo descargar presentaciones desde SlideSharePedro Bermudez Talavera
 

Destaque (8)

cc302modulo3
cc302modulo3cc302modulo3
cc302modulo3
 
Reglas de integridad
Reglas de integridadReglas de integridad
Reglas de integridad
 
Integridad
IntegridadIntegridad
Integridad
 
INTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESS
INTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESSINTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESS
INTEGRIDAD DE ENTIDAD E INTEGRIDAD REFERENCIAL EN SQL SERVER Y ACCESS
 
Reglas de integridad bd relacional
Reglas de integridad bd relacionalReglas de integridad bd relacional
Reglas de integridad bd relacional
 
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
 
Integridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosIntegridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De Datos
 
Cómo descargar presentaciones desde SlideShare
Cómo descargar presentaciones desde SlideShareCómo descargar presentaciones desde SlideShare
Cómo descargar presentaciones desde SlideShare
 

Semelhante a Integridad y seguridad__1er_parcial_bdii

Características avanzadas de SQL.pptx
Características avanzadas de SQL.pptxCaracterísticas avanzadas de SQL.pptx
Características avanzadas de SQL.pptxMairaSantacruz2
 
Integridad Y Seguridad Completo
Integridad Y Seguridad CompletoIntegridad Y Seguridad Completo
Integridad Y Seguridad CompletoDrakonis11
 
Integridad y seguridad de la informacion
Integridad y seguridad de la informacionIntegridad y seguridad de la informacion
Integridad y seguridad de la informacionGabo101101
 
Modelos de bases de datos
Modelos de bases de datosModelos de bases de datos
Modelos de bases de datosJperez98
 
INTEGRIDAD Y SEGURIDAD
INTEGRIDAD Y SEGURIDADINTEGRIDAD Y SEGURIDAD
INTEGRIDAD Y SEGURIDADdemoiselle
 
Analisis comparativo de base de datos
Analisis comparativo de base de datosAnalisis comparativo de base de datos
Analisis comparativo de base de datosmelasa7
 
Sistemas de gestion de base de datos 2º unidad
Sistemas de gestion de base de datos 2º unidadSistemas de gestion de base de datos 2º unidad
Sistemas de gestion de base de datos 2º unidadYoung Hyun
 
Sistemas de gestión de base de datos
Sistemas de gestión de base de datosSistemas de gestión de base de datos
Sistemas de gestión de base de datosCarlos Arturo
 
Acceso a datos en aplicaciones web del entorno servidor
Acceso a datos en aplicaciones web del entorno servidorAcceso a datos en aplicaciones web del entorno servidor
Acceso a datos en aplicaciones web del entorno servidorJomicast
 
Bases de Datos (ACID, Reglas de Codd e Integridad de datos)
Bases de Datos (ACID, Reglas de Codd e Integridad de datos)Bases de Datos (ACID, Reglas de Codd e Integridad de datos)
Bases de Datos (ACID, Reglas de Codd e Integridad de datos)Walter Herrera
 
Instrucciones Transact Sql
Instrucciones Transact SqlInstrucciones Transact Sql
Instrucciones Transact SqlOlaya Molina
 
Instrucciones Transact S Q L
Instrucciones Transact  S Q LInstrucciones Transact  S Q L
Instrucciones Transact S Q LOlaya Molina
 
Diseño de una base de datos
Diseño de una base de datosDiseño de una base de datos
Diseño de una base de datosDorvinEduardo
 
Diseño de una base de datos
Diseño de una base de datosDiseño de una base de datos
Diseño de una base de datosPierina Mv
 

Semelhante a Integridad y seguridad__1er_parcial_bdii (20)

Características avanzadas de SQL.pptx
Características avanzadas de SQL.pptxCaracterísticas avanzadas de SQL.pptx
Características avanzadas de SQL.pptx
 
Integridad Y Seguridad Completo
Integridad Y Seguridad CompletoIntegridad Y Seguridad Completo
Integridad Y Seguridad Completo
 
Integridad y seguridad de la informacion
Integridad y seguridad de la informacionIntegridad y seguridad de la informacion
Integridad y seguridad de la informacion
 
Modelos de bases de datos
Modelos de bases de datosModelos de bases de datos
Modelos de bases de datos
 
Definiciones
DefinicionesDefiniciones
Definiciones
 
INTEGRIDAD Y SEGURIDAD
INTEGRIDAD Y SEGURIDADINTEGRIDAD Y SEGURIDAD
INTEGRIDAD Y SEGURIDAD
 
Analisis comparativo de base de datos
Analisis comparativo de base de datosAnalisis comparativo de base de datos
Analisis comparativo de base de datos
 
Sistemas de gestion de base de datos 2º unidad
Sistemas de gestion de base de datos 2º unidadSistemas de gestion de base de datos 2º unidad
Sistemas de gestion de base de datos 2º unidad
 
Sistemas de gestión de base de datos
Sistemas de gestión de base de datosSistemas de gestión de base de datos
Sistemas de gestión de base de datos
 
Acceso a datos en aplicaciones web del entorno servidor
Acceso a datos en aplicaciones web del entorno servidorAcceso a datos en aplicaciones web del entorno servidor
Acceso a datos en aplicaciones web del entorno servidor
 
Dominios en Base de Datos
Dominios en Base de DatosDominios en Base de Datos
Dominios en Base de Datos
 
Cs2 dominios en bd
Cs2 dominios en bdCs2 dominios en bd
Cs2 dominios en bd
 
Bases de Datos (ACID, Reglas de Codd e Integridad de datos)
Bases de Datos (ACID, Reglas de Codd e Integridad de datos)Bases de Datos (ACID, Reglas de Codd e Integridad de datos)
Bases de Datos (ACID, Reglas de Codd e Integridad de datos)
 
Instrucciones Transact Sql
Instrucciones Transact SqlInstrucciones Transact Sql
Instrucciones Transact Sql
 
Instrucciones Transact S Q L
Instrucciones Transact  S Q LInstrucciones Transact  S Q L
Instrucciones Transact S Q L
 
Modelo de datos
Modelo de datosModelo de datos
Modelo de datos
 
Diseño de una base de datos
Diseño de una base de datosDiseño de una base de datos
Diseño de una base de datos
 
Diseño de una base de datos
Diseño de una base de datosDiseño de una base de datos
Diseño de una base de datos
 
Lenguajes de bases de datos
Lenguajes de bases de datosLenguajes de bases de datos
Lenguajes de bases de datos
 
Base de datos
Base de datosBase de datos
Base de datos
 

Integridad y seguridad__1er_parcial_bdii

  • 1. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL Integridad y Seguridad Introducción Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la perdida de la consistencia de los datos. Por tanto, las restricciones de integridad protegen a la base de datos contra los daños accidentales. Lo habitual en este sentido es limitarse a restricciones de integridad que puedan verificarse con una sobrecarga minima, para el efecto también se puede aplicar la técnica de disparadores lo que ayuda en la validación de la seguridad e integridad. Otro aspecto a ser considerado radica también en la protección que se debe considerar frente a los accesos no autorizados para de esta manera reducir o eliminar los posibles daños. Restricciones sobre atributos Definición de Dominio El asociar un dominio a cada atributo restringe el conjunto de valores que puede tomar ese atributo. Ejemplo: “El tipo de publicación únicamente puede ser Novela, Cuento, Teatro o Poesía”. • Dominios: Dom_tipo : {Novela, Cuento, Teatro, Poesía, ...} • Publicaciones: Publicación(id_lib:dom_id_lib, título:dom_título, tipo:dom_tipo, autor_id:dom_autor_id); Las restricciones de los dominios son la forma más simple de restricción de integridad. Se especifica para cada atributo un dominio de valores posibles. Una definición adecuada de las restricciones de los dominios no sólo permite verificar los valores introducidos en la base de datos sino también examinar las consultas para asegurarse de que tengan sentido las comparaciones que hagan. Por ejemplo, normalmente no se considerará que la consulta “Hallar todos los clientes que tengan el nombre de una sucursal” tenga sentido. Por tanto, nombre-cliente y nombre-sucursal deben tener dominios diferentes. La cláusula check de SQL:1999 permite restringir los dominios de maneras poderosas que no permiten la mayor parte de los sistemas de tipos de los lenguajes de programación. La cláusula check permite especificar un predicado que debe satisfacer cualquier valor asignado a una variable cuyo tipo sea el dominio. Por ejemplo: Número de cifras Número de decimales create domain sueldo-por-hora numeric(4,2) constraint comprobación-valor-sueldo check(value ≥ 6.00) Según [Korth y Silberschatz] Restricciones de dominio Los límites de dominios son la forma más elemental de restricciones de integridad. Son fáciles de probar por el sistema siempre que se introduce un nuevo dato en la base de datos. Es posible que varios atributos tengan el mismo dominio. Por ejemplo, los atributos nombre- cliente y nombre empleado podrían tener el mismo dominio, el conjunto de todos los nombres de personas. Sin embargo los dominios de saldo y nombre-sucursal, por supuesto, deben ser distintos. En el nivel de implementación, los nombres de cliente y los nombres de sucursal son 1
  • 2. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL cadenas de caracteres. Podemos ver que una definición adecuada de restricciones de dominio no sólo nos permite probar valores insertados en la base de datos sino que también nos permite probar consultas para asegurar que la comparación que se hace tiene sentido. Las restricciones de dominio especifican que el valor de cada atributo A debe ser un valor atómico del dominio dom(A) para ese atributo. Los tipos de datos asociados a los dominios por lo general incluyen los tipos de datos numéricos estándar de los números enteros (como entero- corto, entero, entero-largo) y reales (flotante y flotante de doble precisión). También disponemos de caracteres, cadenas de longitud fija y cadenas de longitud variable, así como tipos de datos de fecha, hora, marca de tiempo y dinero. Otros dominios posibles se pueden describir mediante un intervalo de valores de un tipo de datos o como un tipo de datos enumerado en el que se listan explícitamente todos los valores posibles. Restricción de Valores Nulos Para determinado atributos, los valores nulos pueden ser inapropiados. Considérese una tupla en la relación cliente la que nombre-cliente es un valor vació. Una tupla de este tipo da una calle y una ciudad para un cliente anónimo y, por tanto, no contiene información útil. En casos como éste, deseamos prohibir los valores nulos, restringiendo el dominio de ciudad-cliente para que excluya los valores nulos. El SQL estándar permite que la declaración del dominio de un atributo incluya la especificación not null . Esto prohíbe la inserción de un valor nulo para este atributo. Cualquier modificación de la base de datos que causara que se insertase un valor nulo en un dominio not null genera un diagnóstico de error. Hay muchas situaciones en las que la prohibición de valores nulos es deseable. Un caso particular en el que es esencial prohibir los valores nulos es en la clave primaria de un esquema de relación Restricciones de existencia Dentro de las restricciones de los dominios, un tipo especial de restricción que se puede aplicar a cualquier dominio es la restricción de existencia. Esta restricción evita la aparición de valores nulos en las columnas. Restricción de Valor No Nulo La definición de una restricción de valor no nulo sobre un conjunto de atributos K de la relación R expresa la siguiente propiedad: “no debe haber en R una tupla que tenga el valor nulo en algún atributo de K”. Si muchos de los tributos no se aplican a todas las tuplas de la relación, se acabará con un gran número de nulos en esas tuplas. Esto puede originar un considerable desperdicio en el nivel de almacenamiento y posiblemente dificultar el entendimiento del significado de los atributote y la especificación de operaciones de Reunión con en el nivel lógico. Otro problema con los nulos es cómo manejarlos cuando se aplican funciones agregadas como COUNT o SUM. Además, los nulos pueden tener múltiples interpretaciones, como los siguientes: • El atributo no se aplica a esta tupla • Se desconoce el valor del atributo para esta tupla. • El valor se conoce pero está ausente; esto es, todavía no se ha registrado. Tener la misma representación para todos los nulos puede hacer que se confundan los diferentes significados que podrían tener. Por tanto, hasta donde sea posible, evite incluir en una relación base atributos cuyos valores puedan ser nulos. Si no es posible evitar los nulos, asegúrese de que se apliquen sólo en casos excepcionales. 2
  • 3. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL Ejemplo: VNN: { título } “No debe haber en Publicación una tupla que tenga el valor nulo en algún atributo de título”. Formalmente esta restricción se define como: ∀t:Publicación ( nulo(t.título)) Restricción de aserción Una Técnica más formal para representar restricciones explícitas es con un lenguaje de especificación de restricciones , que suele basarse en alguna variación del cálculo relacional. Este enfoque declarativo establece una separación clara entre la base de restricciones (en la que las restricciones se almacenan en una forma codificada apropiada) y el subsistema de control de integridad del SGBD (que tiene acceso a la base de restricciones para aplicar estas últimas correctamente a las transacciones afectadas). Cuando se usa esta técnica, las restricciones suelen llamarse aserciones . Se ha sugerido el uso de esta estrategia con SGBD relaciónales. El subsistema de control de integridad compila las aserciones, que entonces se almacenan en el catalogo del SGBD, donde el subsistema de control de integridad puede consultarlas e imponerlas automáticamente. Esta estrategia es muy atractiva desde el punto de vista de los usuarios y programadores por su flexibilidad. Según [Elmasri / Navathe ] Las restricciones de integridad protegen la base de datos contra daños accidentales. Una base de datos almacena información sobre alguna parte del mundo real, a la que denominamos o universo de discurso . Ciertas reglas, las restricciones de integridad, gobiernan el minimundo. Cuando diseñamos un esquema para una aplicación de base de datos particular, una actividad importante consiste en identificar las restricciones de integridad que se deben cumplir en la base de datos. Restricciones de unicidad La definición de una restricción de unicidad sobre un conjunto de atributos K de la relación R expresa la siguiente propiedad: “no debe haber en R dos tuplas que tengan el mismo valor en todos los atributos del conjunto K”. Ejemplo: Uni: {id_lib} “No debe haber en Publicación dos tuplas que tengan el mismo valor en el atributo id_lib”. Formalmente esta restricción se define como: (∃t1:Publicación (∃t2:Publicación (t1≠t2 ∧t1.id_lib = t2.id_lib ∧ nulo(t1.id_lib) ∧ nulo( t2.id_lib)))) Otro tipo especial de restricción que se puede aplicar a cualquier dominio es la restricción de unicidad. Esta restricción evita la aparición de valores duplicados en las columnas. Por ejemplo: Sólo se admite una sucursal en cada ciudad. CREATE TABLE Sucursales (nombre-sucursal VARCHAR(20), ciudad-sucursal VARCHAR(20) NOT NULL, - Restricción de existencia PRIMARY KEY(nombre-sucursal) UNIQUE (ciudad-sucursal)) - Restricción de unicidad Bases de datos y sistemas de información Clave Primaria Las claves se usan para acceder a las tablas, y existen dos tipos: Claves primarias y Claves foráneas. Una Clave primaria identifica unívocamente a un registro en una tabla, mientras que 3
  • 4. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL una Clave foránea accede a la información de otra tabla relacionada por medio de una Clave primaria. Claves Foráneas Las claves se usan para acceder a las tablas: Claves primarias y Claves foráneas. Una Clave primaria identifica únicamente un registro en una tabla, mientras que una Clave foránea accede datos en alguna otra tabla relacionada por su Clave primaria. Las claves foráneas se representan en el UML de Enterprise Architect usando operaciones estereotipadas. Una Clave foránea es una colección de columnas (atributos) que en conjunto tienen algún significado operacional (fuerzan una relación a una Clave primaria en otra tabla). Una clave foránea se modela como una operación estereotipada con el estereotipo FK; los parámetros de la operación pasan a ser las columnas involucradas en la clave. Tenga en Cuenta: Es necesario definir una Clave foránea para acceder otra tabla a través de su Clave primaria. Las Claves primarias son una característica de algunos sistemas de administración de basededatos, proporcionando "extras" como verificación de integridad referencial que previene la eliminación de un registro si su valor de clave primaria existe en alguna otra clave foránea de la tabla. La mismas cosas se pueden obtener programáticamente. Para crear una clave foránea, haga clic en el vínculo. También puede tener que definir una plantilla de nombre para las claves foráneas. Integridad Referencial Según [Korth y Silberschatz] A menudo queremos asegurar que un valor que aparece en una relación para un conjunto de atributos dado también aparece para un cierto conjunto de atributos en otra relación. Esto se llama integridad referencial. Las restricciones de integridad referencial se representan frecuentemente. Si obtenemos el esquema de base de datos relacional construyendo tablas desde diagramas E-R, entonces todas las relaciones que surgen de un conjunto de relaciones tienen restricciones de integridad referencial. Un conjunto de relaciones n-ario R, referente a los conjunto de entidades E1, E2, …, En. Ki representa la clave primaria de Ei. Los atributos del esquema de relaciones para el conjunto de relaciones R incluyen K1 È K2 È … È Kn. Cada Ki del esquema de R es una clave exterior que conduce a una restricción de integridad referencial Según [Elmasri / Navathe] La restricción de integridad referencial se especifica entre dos relaciones y sirve para mantener la consistencia entre tuplas de las dos relaciones. En términos informales, la restricción de integridad referencial establece que una tupla en una relación que haga referencia a otra relación deberá referirse a una tupla existente en esa relación. Por ejemplo, en la fig. 3.17 el atributo ND de EMPLEADO da el número del departamento para el cual trabaja cada empleado; por tanto, su valor en cada tupla de EMPLEADO deberá coincidir con el valor de NÚMEROD en alguna tupla de la relación DEPARTAMENTO. EMPLEADO NOMBREE NSS FECHAN DIRECCIÓN ND Silva, José B. 123456789 09-ENE-55 Fresnos 731, Higueras, MX 5 Vizcarra, Federico 333445555 08-DIC-45 Valle 638, Higueras, MX 5 Zapata, Alicia J. 999887777 19-JUL-58 Castillo 3321, Sucre, MX 4 4
  • 5. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL Valdés, Jazmín S. 987654321 20-JUN-31 Bravo 291, Belén, MX 4 Nieto, Ramón K 666884444 15-SEP-52 Espiga 957, Heras, MX 5 Esparza, Josefa A. 456456456 31-JUL-62 Rosas 5631, Higueras, MX 5 Jabbar, Ahmed V. 987987987 29-MAR-59 Dalias 980, Higueras, MX 4 Botello, Jaime E. 888665555 10-NOV-27 Sorgo 450, Hogueras, MX 1 DEPARTAMENTO NÚMEROD NSSGTED NOMBRED Investigación 5 333445555 Administración 4 987654321 Dirección 1 888665555 Figura 3.17. Ejemplos de relaciones EMPLEADO y DEPARTAMENTO Resumen A menudo queremos asegurar que un valor que aparece en una relación para un conjunto de atributos dado también aparece para un cierto conjunto de atributos en otra relación. Esto se llama integridad referencial. En términos informales, la restricción de integridad referencial establece que una tupla en una relación que haga referencia a otra relación deberá referirse a una tupla existente en esa relación. Por ejemplo, en la fig. 3.17 el atributo ND de EMPLEADO da el número del departamento para el cual trabaja cada empleado; por tanto, su valor en cada tupla de EMPLEADO deberá coincidir con el valor de NÚMEROD en alguna tupla de la relación DEPARTAMENTO. NOMBREE NSS FECHAN DIRECCIÓN ND Silva, José B. 123456789 09-ENE-55 Fresnos 731, Higueras, MX 5 Vizcarra, Federico 333445555 08-DIC-45 Valle 638, Higueras, MX 5 Zapata, Alicia J. 999887777 19-JUL-58 Castillo 3321, Sucre, MX 4 Valdés, Jazmín S. 987654321 20-JUN-31 Bravo 291, Belén, MX 4 Nieto, Ramón K 666884444 15-SEP-52 Espiga 957, Heras, MX 5 Esparza, Josefa A. 456456456 31-JUL-62 Rosas 5631, Higueras, MX 5 Jabbar, Ahmed V. 987987987 29-MAR-59 Dalias 980, Higueras, MX 4 Botello, Jaime E. 888665555 10-NOV-27 Sorgo 450, Hogueras, MX 1 NOMBRED NÚMEROD NSSGTED Investigación 5 333445555 Administración 4 987654321 Dirección 1 888665555 Figura 3.17. Ejemplos de relaciones EMPLEADO y DEPARTAMENTO • Reglas de Relación Según [Elmasri / Navathe] • Orden de las tuplas en una relación: una relación se define como un conjunto de tuplas matemáticamente, los elementos de un conjunto no están ordenados; por tanto, las tuplas de una relación no tienen orden específico. 5
  • 6. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL El ordenamiento de las tuplas no forma parte de la definición de una relación, porque la relación intenta representar los hechos en un nivel lógico abstracto. • Orden de los valores dentro de una tupla, y definición alternativa de relación: Una tupla es una lista ordenada de n valores, así que el orden de los valores de una tupla y por tanto de los atributos en la definición de un esquema de relación es importante. No obstante, en un nivel lógico, el orden de los atributos y de sus valores en realidad no es importante en tanto se mantengas la correspondencia entre atributos y valores. • Valores en las Tuplas: Cada valor en una tupla es un valor atómico; esto es, no es divisible en componentes en lo que respecta al modelo relacional. Por ello no se permiten valores compuestos ni multivaluados. Reglas de base de datos Según [Elmasri / Navathe] • Una base de datos representa algún aspecto del mundo real, en ocasiones llamado minimundo o universo de discurso. Las modificaciones del minimundo se reflejan en la base de datos. • Una base de datos es un conjunto de datos lógicamente coherente, con cierto significado inherente. Una colección aleatoria de datos no puede considerarse propiamente una base de datos. • Toda base de datos se diseña, construye y prueba con datos para un propósito específico. Esta dirigida a un grupo de usuarios y tiene ciertas aplicaciones preconcebidas que interesan a dichos usuarios. En otras palabras, una base de datos tiene una fuente de la cual se derivan los datos, cierto grado de interacción con los acontecimientos del mundo real y un público que está activamente interesado en el contenido de la base de datos. • Reglas de negocios Según [Elmasri / Navathe] Una base de datos almacena información sobre alguna parte del mundo real, a la que denominamos minimundo o universo de discurso. Ciertas reglas, las restricciones de integridad, gobiernan el minimundo, y suelen recibir el nombre de reglas de negocios. Cuando diseñamos un esquema para una aplicación de base de datos particular, una actividad importante consiste en identificar las restricciones de integridad que se deben cumplir en la base de datos. Según [ David M. Kroenke] El último elemento de un esquema de base de datos son las reglas de negocios. Son restricciones en las actividades de negocios que necesitan reflejarse en la base de datos y en sus aplicaciones. Los siguientes son ejemplos de reglas de negocios para Highline Collage: 1. Para pedir prestado cualquier equipo, un capitán debe tener un número de teléfono local. 2. Ningún capitán puede tener prestadas a la vez más de siete pelotas de soccer. 3. Los capitanes deben regresar todo el equipo dentro de los cinco días posteriores al final de cada semestre. 4. Ningún capitán puede pedir prestado más equipo si tiene algún material vencido. 6
  • 7. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL Las reglas de negocios son una parte importante del esquema porque especifican las limitaciones sobre los valores de datos permitidos que deben cumplirse, sin importar la forma en la que los cambios en los datos llegan al motor DBMS. Sin tomar en cuenta si una solicitud no válida de un cambio de datos viene del usuario de una forma, de una solicitud de consulta/actualización o de un programa de aplicación, el DBMS lo debe rechazar. Los actuales productos DBMS sólo ofrecen un cumplimiento limitado de las reglas de negocios, de modo que la mayor parte de las reglas deben cumplirse mediante programas de aplicación y procedimientos llevados a cabo por el usuario. La situación está cambiando y se están desarrollando productos DBMS para cumplir las reglas de negocios. Resumen Las reglas de negocios son restricciones en las actividades de negocios que necesitan reflejarse en la base de datos y en sus aplicaciones. Los siguientes son ejemplos de reglas de negocios para Highline Collage: 1. Para pedir prestado cualquier equipo, un capitán debe tener un número de teléfono local. 2. Ningún capitán puede tener prestadas a la vez más de siete pelotas de soccer. 3. Los capitanes deben regresar todo el equipo dentro de los cinco días posteriores al final de cada semestre. 4. Ningún capitán puede pedir prestado más equipo si tiene algún material vencido. Las reglas de negocios son una parte importante del esquema porque especifican las limitaciones sobre los valores de datos permitidos que deben cumplirse, sin importar la forma en la que los cambios en los datos llegan al motor DBMS. Sin tomar en cuenta si una solicitud no válida de un cambio de datos viene del usuario de una forma, de una solicitud de consulta/actualización o de un programa de aplicación, el DBMS lo debe rechazar. Restauración de la Integridad referencial La regla de integridad referencial se enmarca en términos de estados de la base de datos: nos dice lo qué es un estado ilegal ¡¡pero no nos dice cómo podemos evitarlo!! ¿Qué hacer si estando en un estado legal, llega una operación que conduce a un estado ilegal? Existen dos opciones: • Rechazar la operación. • Aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal. Es tarea del diseñador de la base de datos indicar qué operaciones sedeben rechazar y cuales requieren operaciones adicionales, u operaciones de compensación. 7
  • 8. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos? Regla de borrado: ¿Qué hacer si se intenta borrar la tupla a la que hace referencia una clave ajena? • Restringir • Propagar • Anular Regla de modificación: ¿Qué hacer si se intenta modificar el valor de la clave primaria de la tupla a la que hace referencia una clave ajena? • Restringir • Propagar • Anular Diccionario de bases de datos El diccionario de datos guarda y organiza los detalles del Diagrama de Flujo de Datos (DFD). Es el segundo componente del análisis estructurado. También se conoce como "Data Repository". Incluye el contenido de los data flow (flujos de datos), los "data store", las entidades externas y los procesos. 3.6.1 Concepto Según [David M. Kroenke] Un diccionario de datos es una herramienta de importancia para el administrador de la base de datos, es un catalogo accesible para el usuario de datos relacionados. Con la base de datos. Según [Elmasri/Navathe] Con el termino de diccionario de datos suele designarse una utilería de software más general que un catalogo. Los sistemas de diccionario de datos sirven para mantener información relativa al hardware y software, la documentación y los usuarios del sistema, así como otra información pertinente para la administración del sistema. Resumen Los sistemas de diccionario de datos sirven para mantener información relativa al hardware y software, la documentación y los usuarios del sistema, así como otra información pertinente para la administración del sistema. Es un catalogo accesible para el usuario de datos relacionados Con la base de datos. 8
  • 9. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL 3.6.2 Contenido y función Según [Korth y Silberschatz] El diccionario de datos almacena información acerca de la estructura de la base de datos, y la información de autorización, y datos acerca de las relaciones. Tipos de información que el sistema debe almacenar están: • Los nombres de las relaciones. • Los nombres de los atributos de cada relación. • Los dominios de los atributos. • Los nombres de las vistas definidas en la base de datos y la definición de esas vistas. • Las restricciones de integridad de cada relación (por ejemplo, las restricciones e clave). Además de esto, muchos sistemas conservan los datos siguientes de los usuarios del sistema: • Nombres de los usuarios autorizados. • Información contable acerca de los usuarios. En los sistemas que utilizan estructuras altamente sofisticadas para almacenar relaciones, pueden conservarse datos estadísticos y descriptivos acerca de las relaciones: • Número de tuplas en cada relación. • Método de almacenamiento utilizado para cada relación (por ejemplo, agrupado o sin agrupar). Tipos Según [Elmasri/Navathe] Diccionario de datos Activo: Es un diccionario cuyas entradas son modificadas en forma automática por el software, siempre que ocurran modificaciones en la escritura de la base de datos. Diccionario de datos Pasivo: necesitan ser actualizados en forma separada, para hacer modificaciones en la base de datos, de lo contrario no reflejarán con exactitud el estado de la base de datos. Los diccionarios de datos Activos cuestan más, pero aseguran se actualicen; no están disponibles con todos los productos DBMS. Los diccionarios de datos pasivos son menos costosos que los activos, pero se requiere de mayor esfuerzo para mantenerlos actualizados. Cualquiera de ellos es una gran ayuda al DBA para registrar y rastrear nombres, formatos, relaciones y referencias cruzadas de los datos. Estructura de un Diccionario de datos (Data Dictionary) Data elements (elementos de datos) Es la parte más pequeña de los datos que tiene significado en el sistema de información. Se combinan varios elementos de datos para hacer los records o "data structures". Ejemplo: nombre, dirección, seguro social. Data Structure (Estructura de datos) También se conocen como record. Es la combinación de elementos de datos relacionados que se incluye en un flujo de datos o se retiene en un "data store". Documentación: Data elements - Las características que se describen en el diccionario de datos son: 1. Name - Es el nombre del elemento de datos; debe ser significativo. 2. Alias - Cualquier otro nombre que se pueda usar para referirse al elemento de datos. Por ejemplo, el nombre de un elemento de datos puede ser Balance actual, y el alias puede ser Deuda. Solo se incluye el alias si realmente es necesario utilizarlo. 9
  • 10. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL 3. Type y Size - Type o tipo se refiere a si el elemento de datos contiene valor numérico, caracteres o alfabético. Size o tamaño se refiere al máximo de caracteres o de dígitos que puede tener el elemento de datos. 4. Output format or edit mask - Indica cómo se presenta el dato al mostrarse en pantalla o al imprimirse en un reporte. Por ejemplo, el número de teléfono del cliente se puede guardar en el disco usando solo números 7878889999, pero presentarse editado en la pantalla o en el reporte (787) 888-9999. 5. Default value - Es el valor que el elemento de datos tiene si no se cambia entrando otro valor. 6. Prompt, column header or field caption - Es el nombre que se presenta en la pantalla o el título del dato en el reporte. 7. Source - De dónde se origina el valor del elemento de datos. Puede ser una forma, un departamento, otro sistema, etc. 8. Security - Identifica los individuos o departamentos que pueden modificar el elemento de datos. Por ejemplo, la línea de crédito puede ser cambiada por el gerente de crédito. 9. Responsible user(s) - Identifica el (los) usuarios responsables de entrar o cambiar los valores del elemento de datos. 10. Acceptable Data and Data validation - Se especifica el dominio o valores permitidos. Pueden ser valores específicos, una lista de valores, los valores que se encuentren en otro archivo, etc. El valor puede tener reglas de validación; por ejemplo, el salario debe estar entre lo permitido para la posición que el empleado ocupa. 11. Derivation formula - Si el valor es el resultado de un cálculo, se muestra la fórmula que se utiliza. 12. Description or comments - Para proveer información adicional, notas o descripciones. Data flows (Flujo de datos) - Las características que se describen en el flujo de datos son: 1. Name – El nombre del flujo de datos tal y como aparece en el DFD. 2. Alias – Otro nombre con que se conozca el flujo de datos. 3. Abbreviation or ID – Código que provee acceso rápido al flujo de datos en un diccionario de datos automatizado. 4. Description – Describe el flujo de datos y su propósito. 5. Origin – De donde sale (la fuente) el flujo de datos. Puede ser un proceso, un “data store” o una entidad. 6. Destination – El punto final del flujo de datos en el DFD. Puede ser un proceso, un “data store” o una entidad. 7. Record – Cada flujo de datos representa un grupo de elementos de datos relacionados, o un record. Los records y los flujos de datos se definen por separado para que más de un flujo de datos o “data store” pueda hacer referencia al mismo record. 8. Volume and frequency – Describe el número esperado de ocurrencias para el flujo de datos por unidad de tiempo. “Data store” – Las características que se describen en el “data store” son: 1. Name – El nombre del “data store” según aparece en el DFD. 2. Alias – Otro nombre con el que se pueda llamar al “data store”. 3. Abbreviation or ID – Código que provee un acceso rápido al “data store” en un diccionario de datos automatizado. 4. Description – Describe el “data store” y su propósito. 5. Input data flows – Los nombres de los flujos de datos que entran al “data store”. 6. Output data flows – Los nombres de los flujos de datos que salen del “data store”. 7. Record – El nombre del record en el diccionario de datos para el “data store”. 8. Volume and Frequency – El número estimado de records guardados en el “data store”, al igual que el aumento o cambio esperado. 10
  • 11. “Escuela Militar de Ingeniería” Mcal. Antonio José de Sucre Base de Datos II Análisis de Sistemas Ing. Osamu Yokosaki INTEGRIDAD DE UNA BASE DE DATOS RELACIONAL Proceso – Se documenta cada función primitiva. Se incluye: 1. Process name or label – El nombre del proceso como aparece en el DFD. 2. Purpose or description – Un resumen del propósito general del proceso. Los detalles se documentan en el Process Description. 3. Process number – Número de referencia que identifica el proceso y su relación con los niveles del sistema. 4. Input data flows – Los nombres de los flujos de datos que entran al proceso. 5. Output data flows – Los nombres de los flujos de datos que salen del proceso. 6. Process Description – Se explican los detalles del proceso. Entidades Externas – Las características que se describen son: 1. Name 2. Alias 3. Description – Describe a la entidad y su propósito. 4. Input data flow 5. Output data flow Record – Se describe lo siguiente: 1. Record name 2. Alias 3. Description 4. Record content or composition – Una lista de todos los elementos de datos incluidos en el record. Se identifica cualquier “key” primario, o sea un elemento de datos en el record que identifica en forma única al record. 11