Integridad y seguridad__1er_parcial_bdii

“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

1

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



2

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.



3

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



4

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



5

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

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 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.



6

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.



7

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.



8

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.



9

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.



10

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.



11

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.

Integridad y seguridad__1er_parcial_bdii

Documents

Transcript of Integridad y seguridad__1er_parcial_bdii