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