El diccionario de datos



Descargar 81.57 Kb.
Fecha de conversión07.02.2019
Tamaño81.57 Kb.


EL DICCIONARIO

DE DATOS

Los diccionarios son como los relojes: el peor es mejor que no tener

ninguno y del mejor no puede esperarse que sea muy exacto.

Sra. Priozzi, Anécdotas de Samuel Johnson, 1786.





En este capítulo se aprenderá:

  1. Por qué se necesita un diccionario de datos en un proyecto de desarrollo de sistemas.

  2. La notación de las definiciones de los diccionarios de datos.

  3. Cómo debe presentarse el diccionario de datos al usuario.

  4. Cómo realizar un diccionario de datos.

La segunda herramienta de modelado importante que discutiremos es el diccionario de datos; aunque no tiene la presencia ni el atractivo gráfico de los DFD, los diagramas de entidad-relación y los diagramas de transición de estados, es crucial. Sin los diccionarios de datos, el modelo de los requerimientos del usuario no puede considerarse completo; todo lo que se tendría es un borrador rudimentario, una “visión del artista” del sistema.


La importancia del diccionario de datos a menudo le pasa de largo a muchos adultos, pues no han utilizado un diccionario durante 10 o 20 años. Trate de recordar sus días en la primaria, cuando constantemente se le asediaba con nuevas palabras en sus tareas. Recuerde también sus cursos de lenguas extranjeras, sobre todo los que requerían que leyera libros y revistas. Sin un diccionario, se habría perdido. Lo mismo sucede con un diccionario de datos en el análisis de sistemas: sin él se extraviará y el usuario no podrá estar seguro de que entendió los detalles de la aplicación.
El diccionario de datos de frases casi se autodefine. El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos intermedios. El diccionario de datos define los datos haciendo lo siguiente:


  • Describe el significado de los flujos y almacenes que se muestran en los DFD.




  • Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los flujos, es decir, paquetes complejos (por ejemplo el domicilio de un cliente), que puede descomponerse en unidades más elementales (como ciudad, estado y código postal).




  • Describen la composición de los paquetes de datos en los almacenes.




  • Especifica los valores y unidades relevantes de piezas elementales de información en flujos de datos y en los almacenes de datos.




  • Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relación. Este aspecto del diccionario de datos se discutirá con más detalle en el capítulo 12, después de introducir la notación de entidad-relación.


10.1 LA NECESIDAD DE LA NOTACIÓN EN EL DICCIONARIO DE DATOS
En la mayoría de los sistemas reales con los que se trabaja, los paquetes, o elementos de datos, serán lo suficientemente complejos como para que se necesite describirlos en términos de otras cosas. Los elementos complejos de datos se definen en términos de elementos más sencillos, y los sencillos en términos de los valores y unidades legítimos que pueden asumir.
Imagine, por ejemplo, la forma en la que respondería a las siguientes preguntas de un marciano (que es el concepto que muchos usuarios tienen del analista) acerca del significado del nombre de una persona:
Marciano: “Bien, ¿qué es esto llamado nombre?”
Usted (encogiéndose impacientemente de hombros): “Pues, usted sabe, es sólo un nombre, quiero decir, este, bueno, es los que nos llamamos unos a otros.”
Marciano (confundido): “¿Significa eso que los llama de distinto modo cuando está contento y cuando está enojado?”
Usted (un tanto sorprendido de la ignorancia de este extraterrestre): “No, claro que no. Un nombre es el mismo siempre. Un nombre de persona lo distingue de otras personas.”
Marciano (entendiendo de repente): “¡Ah! Ya entiendo. Hacemos lo mismo en mi planeta. Mi nombre es 3.141592653589793238462643.”
Usted (incrédulo): “Pero eso es un número, no un nombre.”
Marciano: “Y es un muy buen nombre, me enorgullezco de él. Nadie tiene algo parecido.”
Usted: “¿Pero cuál es su nombre y cuál su apellido? ¿O 3 es su nombre y el resto su apellido?
Marciano: “¿Qué es todo esto de nombre y apellido? No entiendo. Tengo un solo nombre y siempre es el mismo.”
Usted: “Pues no funcionan así las cosas aquí. Tenemos un nombre, un apellido, y en ocasiones un segundo nombre también.”
Marciano: “¿Significa eso que usted puede llamarse 23 45 99?”
Usted: “No. No permitimos números en nuestros nombres. Sólo puede usar los caracteres alfabéticos de la A a la Z.”
Como podrá imaginar, la conversación podría continuar durante mucho tiempo. Puede pensar que el ejemplo es exagerado porque rara vez nos encontraremos con marcianos que no tengan el concepto del significado nombre. Pero no está muy alejado de las discusiones que se suscitan (o que debieran suscitarse) entre el analista y el usuario, en las cuales pudieran surgir las siguientes preguntas:


  • ¿Debe tener todo mundo un nombre? ¿Qué tal el personaje “Sr. T” de la popular serie de televisión “Los cuatro fantásticos”?




  • ¿Qué pasa con los signos de puntuación en los apellidos de las personas, por ejemplo “D´Arcy”?







  • ¿Existe una longitud mínima para el nombre de una persona? Por ejemplo, ¿Es legal el nombre “X Y”? (Es fácil imaginarse que pudiera confundir a muchos sistemas de cómputo, pero ¿existe alguna razón legal o de negocios por la cual una persona no pudiera llamarse X y apellidarse Y?)




  • ¿Cómo debemos tratar los sufijos que a veces siguen el apellido? Por ejemplo, se supone que el nombre “Juan Jasso Jr.” Es legítimo, pero ¿se considera el Jr. Como parte del apellido, o en una categoría aparte? Y si está en una nueva categoría, ¿no debiéramos permitir también dígitos, como por ejemplo, Samuel Sosa 3°?

Nótese, por cierto, que ninguna de estas cuestiones tiene algo que ver con la forma en la que se almacenará la información en la computadora; simplemente estamos tratando de determinar, como cuestión de política de negocios, lo que constituye un nombre válido1.

Como se podrá imaginar, se vuelve algo tedioso describir la composición de los elementos de datos en una forma narrativa. Necesitamos una notación concisa y compacta, así como un diccionario normal tiene notación compacta y concisa para definir el significado de las palabras ordinarias.
10.2 NOTACIÓN DEL DICCIONARIO DE DATOS
Existen muchos esquemas de notación comunes utilizados por el analista de sistemas. El que se muestra a continuación es de los más comunes y utiliza varios símbolos sencillos:
= está compuesto de

+ y


() optativo (puede estar presente o ausente)

{} iteración

[] seleccionar una de varias alternativas

** comentario

@ identificador (campo clave) para un almacén

| separa opciones alternativas en la construcción


Por ejemplo, se puede definir el nombre para nuestro amigo marciano así:
nombre = titulo de cortesía + nombre + (segundo nombre) + apellido
título de cortesía = [Sr. | Srita. | Sra. | Dr. | Profesor]
nombre = {carácter legal}
segundo nombre = {carácter legal}
apellido = {carácter legal}
carácter legal = [A-Z | a-z | 0-9 | ´ | - | |]
Como puede apreciarse, los símbolos parecen algo matemáticos y pudiera preocuparse porque sea demasiado complicado de entender. Sin embargo, como veremos pronto, la notación es bastante fácil de leer. La experiencia de miles de proyectos de procesamiento de datos y varias decenas de miles de usuarios nos ha mostrado que la notación además, es bastante entendible para casi todos los usuarios si se presenta de manera correcta; discutiremos esto en la sección 10.3
10.2.1 Definiciones
La definición de un dato se introduce con el símbolo “=”. En este contexto, el “=” se lee: “se define como”, o “se compone de”, o simplemente “significa”. Por ello, la notación
A = B + C
Puede leerse de las siguientes maneras:


  • Cuando digamos A, queremos decir una B y una C




  • A se compone de B y C




  • A se define como B y C

Para definir por completo un dato, nuestra definición debe incluir lo siguiente:




  • El significado del dato dentro del contexto de la aplicación de este usuario. Por lo común se ofrece como comentario utilizando la notación “**”.




  • La composición del dato, si se compone de partes elementales con significado.




  • Los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse más.

Así, si estamos construyendo un sistema médico que siga la evolución de los pacientes, podrían definirse los términos peso y estatura de la siguiente manera:


peso = * peso del paciente al ser admitido al hospital *

* unidades: kilogramos; gama: 1-200 *


estatura = * estatura del paciente al ser admitido al hospital *

* unidades: centímetros; escala: 20-200 *


Nótese que hemos descrito las unidades relevantes y la escala relevante entre un par de caracteres “*”. Repetimos que esto es un convenio de notación que muchas organizaciones encuentran adecuado, pero que puede cambiarse de ser necesario.
Además de las unidades y a escala, podría requerirse la especificación de la precisión de la medición del dato. Para datos tipo precio, por ejemplo, es importante indicar si los valores se expresarán en moneda entera o redondeados al último centavo, etc. En muchas aplicaciones científicas y de ingeniería es importante indicar el número de dígitos significativos en el valor de los datos.
10.2.2 Elementos de datos básicos

Las pares elementales de los datos son aquellas para las cuales ya no existe una descomposición con significado dentro del contexto del ambiente del usuario. Esto usualmente es una cuestión de aplicación y es algo que se debe explorar cuidadosamente con el usuario. Por ejemplo, hemos visto en la exposición anterior que el termino nombre puede descomponerse en nombre, segundo nombre, apellido y titulo de cortesía. Pero también en algunos ambientes de usuario no se requiere tal descomposición, ni sea relevante, ni tenga significado (esto es, en ambientes donde los términos apellido, segundo nombre, etc., no tengan significado para el usuario).


Cuando se han identificado los datos elementales, deben introducirse al diccionario de datos. Como se indicó anteriormente, el diccionario de datos debe proporcionar una breve narrativa, encerrada entre caracteres “*”, que describa el significado del término en el contexto del usuario. Desde luego, habrá términos que se definan solos, es decir, cuyo significado es universal para todos los sistemas de información, o donde el analista pudiera estar de acuerdo en que no se necesita aclarar más. Por ejemplo, los siguientes pudieran considerarse términos que se autodefinen en un sistema que maneja información sobre personas:
estatura actual

peso actual

fecha de nacimiento

sexo

teléfono particular
en estos casos no se necesita un comentario narrativo; muchos analistas usan la notación “**” para indicar “sin comentarios” cuando el dato se defina sólo. Sin embargo, es importante especificar los valores y unidades de medida que los datos elementales pueden tomar. Por ejemplo:
peso actual = **

*unidades: libras; escala: 1-400*


estatura actual = **

*unidades: pulgadas; escala: 1-96*


fecha de nacimiento = **

*unidades: días a partir del 1° de enero de 1900; escala: 0-36500*


sexo = *valores: [M | F]*

10.2.3 Datos opcionales
Un dato opcional, como la frase implica, es aquel que puede estar o no presente en un dato compuesto. Existen muchos ejemplos de datos opcionales en sistemas de información.


  • El nombre de un cliente podría no incluir un segundo nombre.




  • El domicilio de un cliente pudiera incluir o no información secundaria, como el número de departamento.




  • El pedido de un cliente pudiera contener el domicilio al que se tiene que mandar la cuenta, el domicilio al que hay que hacer el envío, o ambos.

Las situaciones de este tipo deben verificarse con cuidado con el usuario y deben documentarse precisamente en el diccionario de datos. Por ejemplo, la notación


domicilio de cliente = (domicilio de envío) + (domicilio para cuenta)
significa, literalmente, que el domicilio del cliente pudiera consistir en:


  • Sólo un domicilio de envío

o bien



  • Sólo un domicilio para enviar cuentas

o bien



  • Un domicilio de envio y uno para cuentas

o bien



  • Ninguno de los dos

Esta última posibilidad es dudosa. Es mucho más probable que el usuario realmente quiere decir que el domicilio debe consistir en uno u otro o ambos. Esto pudiera expresarse de la siguiente manera:


domicilio del cliente = [domicilio de envío | domicilio para cuentas |

domicilio de envío + domicilio para cuentas]
Podría también argumentarse que, en un negocio por correspondencia, siempre se requiere un domicilio de envío adonde se deberá mandar la mercancía solicitada por el cliente; un segundo domicilio para el envío de la cuenta es opcional (por ejemplo, el departamento de contabilidad del cliente). Así, es posible que la verdadera política del usuario esté expresada por
domicilio del cliente = domicilio de envío + (domicilio para cuentas)
Desde luego, la única manera de saber esto es pedirle al usuario que explique con cuidado las implicaciones de las diferentes notaciones que se mostraron2.

10.2.4 Iteración
La notación de iteración se usa para indicar la ocurrencia repetida de un componente de un dato. Se lee como “cero o más ocurrencias de”. Así la notación:
solicitud = nombre del cliente + domicilio de envío + {artículo}
significa que la solicitud siempre debe contener un nombre de cliente, un domicilio de envío, y también cero o más ocurrencias de un artículo. Así, pudiéramos estar tratando con un cliente que pide un articulo, o dos, o algún comprador compulsivo que decide ordenar 397 artículos diferentes3.
En muchas situaciones reales, el usuario querrá especificar los límites inferior y superior de la iteración. Tal vez, en el ejemplo anterior, el usuario señale que no tiene sentido que un cliente haga un pedido de cero artículos; debe haber por lo menos uno. Podría también especificarse un limite superior; quizá, se permitan cuando más 10 artículos. Puede indicarse esto de la siguiente forma:
solicitud = nombre del cliente + domicilio de envío + 1{artículo}10
Es correcto especificar sólo el límite inferior, sólo el límite superior, ambos, o ninguno. Así que se permite cualquiera de los siguientes:
a = 1{b}
a = {b}10
a = 1{b}10
a = {b}
10.2.5 Selección
La notación de selección indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Las opciones se encierran en corchetes “[” y “]”, y se separan por una barra vertical “|”. Como ejemplos típicos tenemos:
sexo = [Femenino | Masculino]
tipo de cliente = [Gobierno | Industria | Universidad | Otro]
Es importante revisar las opciones de selección con el usuario para asegurarse de cubrir todas las posibilidades. En un último ejemplo, el usuario pudiera tender a concentrar su atención en los clientes “gobierno”, “industria” y “universidad”, y podría requerir un recordatorio de que existen clientes de la categoría d “ninguno de los anteriores.
10.2.6 Alias
Un alias, como el término implica, es una alternativa de nombre para un dato. Esto es una ocurrencia común cuando se trata con diversos tipos de usuario en diferentes departamentos o ubicaciones geográficas (y a veces con diferentes nacionalidades e idiomas), que insisten en utilizar distintos nombres para decir lo mismo. En alias se incluye en el diccionario de datos para que esté completo, y se relaciona con el nombre primario u oficial del dato. Por ejemplo:
comprador = “alias de cliente”
Nótese que la definición de comprador no muestra su composición (es decir, no muestra que consiste en nombre, domicilio, número telefónico, etc.). Todos estos detalles deben darse sólo para el nombre primario del dato, para minimizar la redundancia en el modelo4.
Aun cuando el diccionario de datos relaciona correctamente los alias con el nombre primario de los datos, debe evitarse el uso de alias hasta donde sea posible. Esto se debe a que los nombres de datos se suelen ver primero, y son más visibles para todos los usuarios en los DFDs, en donde pudiera no ser tan obvio que comprador y cliente son alias. Es mejor, de ser posible, lograr que todos los usuarios se pongan de acuerdo en un solo nombre5.
10.3 COMO MOSTRAR EL DICCIONARIO DE DATOS AL USUARIO
El diccionario de datos lo crea el analista durante el desarrollo del modelo del sistema, pero el usuario debe ser capaz de leerlo y entenderlo para poder verificar el modelo. Esto plantea unas preguntas obvias:


  • ¿Podrán los usuarios entender la notación del diccionario de datos?




  • ¿Cómo podrían los usuarios verificar que el diccionario está completo y correcto?




  • ¿Cómo se crea el diccionario?

La cuestión de la aceptación por el usuario de la notación del diccionario puede despistar en la mayoría de los casos. Es cierto, la notación del diccionario se ve algo matemática; pero, como se ha visto, el número de símbolos que el usuario debe aprender es muy pequeño. Los usuarios están acostumbrados a la variedad de notaciones formales en su trabajo y vida personal; considere, por ejemplo, la notación musical, que es mucho más compleja:




Figura 10.1: Notas musicales
Similarmente, la notación de los juegos de canasta, ajedrez, varias actividades más es cuando menos igual de compleja que la del diccioanrio de datos que se muestra en este capítulo.


Figura 10.2: Notación de ajedrez
La cuestión de la verificación del diccionario de datos por el usuario lleva generalmente a esta pregunta: “¿Deben los usuarios leer en detalle el diccionario para asegurarse que está correcto?”. Es difícil imaginar que algún usuario esté dispuesto a hacer esto. Es más probable que el usuario verifique que el diccionario es correcto en conjunto con el DFD, el diagrama de entidad-relación y el diagrama de transición de estados o la especificación del proceso que esté leyendo.
Hay varios detalles acerca de la corrección del sistema que el analista puede hacer por su cuenta, sin ayuda del usuario: puede asegurarse de que el diccionario esté completo y sea consistente y no contradictorio. Así que puede examinar el diccionario por sí solo y preguntar lo siguiente:


  • ¿Se ha definido en el diccionario cada flujo del DFD?




  • ¿Se han definido todos los componentes de los datos en el diccionario?




  • ¿Se ha definido más de una vez algún dato?




  • ¿Se ha utilizado la notación correcta para todas las definiciones del diccionario de datos?




  • ¿Hay elementos de datos en el diccionario que no estén relacionados con los DFD, los diagramas de entidad-relación o los de transición de estado?


10.4 IMPLANTACIÓN DEL DICCIONARIO DE DATOS
En un sistema mediano o grande, el diccionario de datos puede representar una cantidad formidable de trabajo. No es fuera de lo común ver un diccionario de datos con varios miles de entradas, e incluso un sistema relativamente sencillo tendrá varios cientos de entradas. Así que se debe pensar en cómo desarrollar el diccionario de datos, porque es probable que la tarea sea demasiado para el analista.
El enfoque más fácil es hacer uso de una computadora para introducir definiciones a un diccionario, verificar que estén completas y consistentes, y producir reportes apropiados. Si su organización está utilizando cualquier sistema moderno de administración de base de datos (por ejemplo, IMS, ADABAS, TOTAL, IDMS), ya dispone de una ayuda para el diccionario. En este caso, debiera aprovecharla y utilizarla para construir el diccionario de datos. Sin embargo, debe tener cuidado de las siguientes limitaciones posibles:


  • Pudiera verse forzado a limitar los nombres de datos a cierta longitud (por ejemplo, 15 o 32 caracteres). Esto probablemente no sea un gran problema, pero podría ser que el usuario insista en un nombre como destino-del-envío-del-cliente y que su paquete de elaboración de diccionarios lo obliga a abreviar esto a: dest-env-clien.




  • Podría haber otras limitaciones artificiales para el nombre. Por ejemplo, el carácter “-” pudiera no permitirse, y podría verse forzado a utilizar en su lugar “_”. O podría verse obligado a utilizar prefijos (o sufijos) en todos los nombres, para indicar el nombre del proyecto de desarrollo de sistemas, lo cual lleva a nombres como:


Ctas.pag.GHZ345P14. número_teléfono_vendedor


  • Podría verse obligado a asignarle atributos físicos (por ejemplo, número de bytes, o bloques de almacenamiento en disco, o representaciones como decimales redondeados) a un dato, aún cuando no sea cuestión del usuario. El diccionario de datos que se discute en éste capítulo debe ser un diccionario de análisis y no debiera requerir decisiones de implantación innecesarias o irrelevantes.

Algunos analistas también están empezando a utilizar paquetes automatizados que incluyen gráficos para DFD y otros, además de capacidad para elaborar diccionarios de datos. Nuevamente, si tal ayuda existe, debe aprovecharla. Estos paquetes se discuten con mayor detalle en el apéndice A.


Si no dispone de ayudas automáticas para construir el diccionario de datos, debiera por lo menos hacer uso de un procesador de palabras convencional para crear un archivo de texto de definiciones del diccionario de datos. O, si tiene acceso a una computadora personal, pudiera usar cualquiera de los programas comunes de administración de archivos o bases de datos (por ejemplo, dBASE, Rbase-5000, PFS-File, Microsoft File en la Apple Macintosh) para construir y administrar el diccionario de datos.
Sólo en los casos más extremos debiera recurrir a un diccionario manual, es decir, tarjetas individuales de 3 x 5 para cada entrada del diccionario. Esto a menudo era necesario en los años 70 e incluso en los 80; a pesar de la popularidad de las computadoras personales y los procesadores de palabras, es decepcionante ver cuántas organizaciones han mantenido a sus programadores y analistas en la época del oscurantismo. Los hijos de zapatero, como dice el refrán, son los últimos en recibir zapatos. Pero hoy en día esto es imperdonable. Si está trabajando con un proyecto donde no tiene acceso a un paquete para elaboración de diccionarios de datos o a un paquete automatizado de herramientas para analista, o a una computadora personal o un sistema procesador de palabras, entonces debería 1) renunciar y encontrar un mejor empleo, o 2) conseguir su propia computadora personal, o 3) hacer ambas cosas.
10.5 RESUMEN
Construir un diccionario de datos es una de las labores más tediosas, y largas, del análisis de sistemas. Pero también es una de las más importantes: sin un diccionario formal que defina el significado de los términos, no se puede esperar precisión.
En el siguiente capítulo veremos cómo se usa el diccionario de datos y el DFD para construir especificaciones de proceso para cada uno de los procesos de más bajo nivel.
PREGUNTAS Y EJERCICIOS


  1. Dé una definición de diccionario de datos.




  1. ¿Por qué es importante un diccionario de datos para el análisis de sistemas?




  1. ¿Qué información da un diccionario de datos acerca de un dato?




  1. ¿Qué significa la notación “=” en un diccionario de datos?




  1. ¿Qué significa la notación “+” en un diccionario de datos?

  2. ¿Qué significa la notación “()” en un diccionario de datos?




  1. ¿Qué significa la notación “{}” en un diccionario de datos?




  1. ¿Qué significa la notación “[ | | ]” en un diccionario de datos?




  1. ¿Cree usted que los usuarios con los que trabaja pueden entender la notación de diccionario estándar que se da en éste capítulo? Si no es así, ¿puede sugerir alguna alternativa?




  1. Dé un ejemplo de dato elemental.




  1. De tres ejemplos de datos opcionales.




  1. Cuáles son los posibles significados de lo siguiente:




  1. domicilio = (ciudad) + (estado)




  1. domicilio = calle + ciudad + (estado) + (código postal)




  1. Dé un ejemplo del uso de la notación de iteración.




  1. ¿Cuál es el significado de cada una de las siguientes notaciones?




  1. a = 1{b}




  1. a = {b}10




  1. a = 1{b}10




  1. a = 10{b}10




  1. ¿Tiene sentido definir un pedido de la siguiente manera?


pedido = nombre-del-cliente + domicilio-de-envío + 6{artículo}
¿Por qué? O ¿Por qué no?


  1. Dé un ejemplo de la construcción de selección.




  1. ¿Qué significado tiene un alias en el diccionario de datos?




  1. ¿Por qué debieran usarse lo menos posible los alias?




  1. ¿Qué tipo de anotaciones debe hacerse en el DFD para indicar que un dato es un alias?




  1. ¿Cuáles son los tres asuntos de importancia que surgen cuando el usuario ve el diccionario de datos?




  1. ¿Cree usted que los usuarios e su organización podrán entender la notación del diccionario de datos?




  1. ¿Cree usted que la notación que se muestra en este capítulo sea más compleja, o menos, que la musical?




  1. ¿Cuáles son las tres actividades de verificación de posibles errores que puede llevar a cabo el analista en el diccionario de datos sin ayuda del usuario?




  1. ¿Cuáles son las limitaciones probables de un paquete automatizado de generación de diccionario de datos?




  1. Dé una definición de diccionario de datos de nombre-del-cliente basada en la siguiente especificación verbal del usuario: “Cuando registramos el nombre de un cliente, tenemos cuidado de incluir un título de cortesía, que puede ser ‘Sr.’, ‘Srita.’, ‘Sra.’ O ‘Dr.’. (Existen otros muchos títulos como ‘Profesor’, ‘Sir’, etc., pero no nos ocupamos de ellos.) Cada uno de nuestros clientes tiene un nombre de pila, pero permitimos sólo una inicial si ellos lo prefieren. Los segundos nombres son opcionales. Y, desde luego, se requiere el apellido; permitimos una buena gama de apellidos, incluyendo los que conllevan guión (‘Smith-Frisby’, por ejemplo) y apóstrofe (‘D´Arcy’), etc. Incluso permitimos un sufijo optativo, para dar cabida a cosas como ‘Tom Smith Jr.’ o ‘Harvey Shmrdlu 3°’.




  1. ¿Qué está mal en las siguientes definiciones de diccionarios de datos?




  1. a = b c d




  1. a = b + + c




  1. a = {b




  1. a = a{b}3




  1. a = {x)




  1. x = ((y))




  1. p = 4{6{y}8}6




  1. En el ejemplo del hospital de la sección 9.2, ¿qué implican las definiciones de peso y estatura? Comentario: Implicaría que sólo estamos midiendo en unidades enteras y no estamos considerando las fracciones adicionales, etc.

1 Por otro lado, es probable que la política de negocios actual haya tenido una fuerte influencia de los sistemas de cómputo que la organización ha estado usando durante los últimos 30 años. Hace 50 años se hubiera considerado excéntrico a alguien que se hiciera llamar “Jua5n So7to”, pero probablemente hubiera sido aceptado por la mayoría de las organizaciones, porque los nombres se transcribían en pedazos de papel por manos humanas. Los sistemas puramente computacionales (como la mayoría de los de uso actual) tienen muchos más problemas con nombres no estándar como

2 Existe una posibilidad que pudiera explicar la ausencia tanto del domicilio de envío como del de cobro en un pedido de un cliente: el cliente que llega personalmente para comprar un artículo y llevárselo en el acto. Es posible que se le quisiera identificar explícitamente (definiendo un nuevo dato en persona, que tendría valor de verdadero o falso) ya que 1) los clientes que llegan en persona pudieran requerir un trato distinto (por ejemplo, sus pedidos estarían exentos de cargos de envío) y 2) es una buena forma de asegurarse de que la ausencia del dato de domicilio no fue por error.


3 Tenga en mente nuevamente que estamos definiendo el significado intrínseco de negocios de un dato dado sin referirnos a la tecnología usada para implantarlo. A la larga, por ejemplo, es probable que los diseñadores pregunten sobre un límite superior razonable o el número de artículos diferentes que puede contener un mismo pedido. “Para poder lograr una labor eficiente de nuestro sistema SUPERMARAVILLA de administración de bases de datos, tendremos que restringir el número de artículos a 64. Es poco probable de todos modos, que alguien pida más de 64 y, si lo hacen, pueden sencillamente colocar varios pedidos”. Además, el usuario pudiera tener sus propias limitaciones, basadas en las formas escritas o los reportes impresos con los que trabaja; esto es parte del modelo de implantación del usuario, que se tratará en el capítulo 21.

4 Tal vez pueda ignorar este consejo si está utilizando un paquete computarizado de generación de diccionarios de datos que pueda manejar y controlar la redundancia; sin embargo, esto es poco común. Lo crucial es recordar que si se cambia la definición de un dato primario (por ejemplo, si se decide que la definición de cliente ya no debe incluir número telefónico), entonces el cambio se debe aplicar a todos los alias también.

5 Una alternativa sería anotarle algo al flujo en el diagrama de flujo de datos para indicar que es alias de otra cosa: por ejemplo, se podría agregar un asterisco al final a los nombres que son alias. De esta forma, la notación comprador* podría usarse para indicar que comprador es alias de otra cosa. Pero incluso esto es molesto.



Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal