Prácticas de Bases de Datos 2 EI, MI Facultade de Informática UDC. Comentarios sobre las prácticas y los errores más frecuentes

Transcripción

1 Prácticas de Bases de Datos 2 EI, MI Facultade de Informática UDC Comentarios sobre las prácticas y los errores más frecuentes Luis G. Ares (luis.ares@udc.es) A Coruña, 31 de mayo de 2011

2 Contenido 1. Introducción Errores habituales de este curso Redundancia Atributos que forman parte de las claves primarias Índices propuestos MATCH Modelo que prescinde del planteamiento temporal Cosas sorprendentes Detalles destacados Consideraciones iniciales (otros cursos) Notas Problemas con Oracle Tratamiento de las claves foráneas Nombrar las restricciones Tratamiento de la integridad Trabajo en equipo Los dominios en el modelo relacional Nomenclatura VARCHAR2 de Oracle Resta de fechas (años de trabajo, edad actual) Colocación de las claves primaria y foráneas en una tabla Columnas de tipo DATE como parte de claves primarias o claves foráneas Errores frecuentes (otros cursos) Redundancia Incongruencias en la documentación Inadecuado trabajo en equipo Errores en las restricciones Usar los mismos nombres para columnas con significado diferente Uso de sinónimos Dominios Nombres de claves foráneas al estilo balear Representación gráfica de las claves foráneas compuestas Incluir en un CHECK una lista extensa de valores Vinculaciones mal representadas en el esquema relacional Subclase con tipo de relación 1:N o N:M fusionada con la superclase

3 4.13. Pasar una categoría al modelo relacional de forma errónea Consultas SQL Reducida capacidad de explicación y de claridad Otros detalles importantes Diseño acorde a la LOPD

4 1. Introducción El objetivo de este documento es comunicar los errores más frecuentes que se han cometido en las prácticas. Si se desea información adicional, debe ponerse en contacto con los profesores. En este curso se han cometido errores importantes y lo peor es que algunos de ellos coinciden con los de cursos anteriores. Por ello se mantienen los comentarios realizados en otros cursos. Las notas de la primera práctica se han estandarizado entre 0 y 10, pero en las restantes entre 0 y Errores habituales de este curso Además de muchos de otros cursos, en éste encontramos de forma especial los siguientes: 2.1. Redundancia Uno de los errores más comunes es el relativo a las redundancias. Al tratarse de algo que ya estaba mencionado en 4.1 resulta aún más sorprendente, porque su aparición fue muy generalizada, incluso en trabajos bastante buenos. Y más sorprendente resulta por ser algo comentado en varias clases a lo largo del curso por los dos profesores de la asignatura. Atributos como deporte, género, y otros que suponen algún tipo de clasificación, se han colocado literalmente, generando una redundancia exagerada y sorprendente. Se ha decidido destacarlo como error frecuente, por si el hecho de aparecer en otra sección en el documento del curso anterior, conllevó que no se reparase en él. Hay que recordar que el objetivo principal de es almacenar correctamente los datos de una actividad. Pero el almacenamiento correcto, no significa necesariamente que deban leerse fácilmente las tablas, porque no es algo destinado exclusivamente a un usuario final, sino que el diseño debe evitar problemas relacionados con la redundancia, con las inconsistencias, con el rendimiento, con que los datos puedan cumplir las condiciones del mundo real, etc. y todo ello condiciona el diseño. Para que se lean bien los datos, están las consultas y las vistas. Esto entronca con otros casos en los que aparecían tablas que no seguían un buen diseño porque realmente almacenaban datos que deberían ser resultados de consultas. 3

5 2.2. Atributos que forman parte de las claves primarias Normalmente los atributos que forman parte de las claves primarias no deben ser corresponder a datos alfanuméricos que tengan una gran longitud. Para ello se codifican los valores, normalmente con valores enteros, facilitando su utilización en los índices. Se ha comentado también que los atributos de tipo tiempo, en general no constituyen una buena elección para las claves primarias. Lo que pasa es que en el contexto planteado, la importancia del tiempo es fundamental, por lo que aquí puede optarse por la utilización generalizada de columnaas de tipo date como parte de claves primarias Índices propuestos Los índices propuestos han sido muy pocos y muy mal justificados. Se pretendía que se revisasen las consultas habituales y que eso llevase a decidir qué índices se necesitaban, más allá de los habituales MATCH Aunque Oracle no lo permita, el MATCH era necesario declararlo en las columnas que forman parte de claves foráneas de más de una columna. Prácticamente nadie los menciona Modelo que prescinde del planteamiento temporal Aunque esto es una crítica de la primera parte, hay que destacar que el ejemplo planteado ofrecía muchas posibilidades de tratamiento temporal, ya que prácticamente todo en él es temporal: canales, paquetes, ofertas, programas, presentadores, etc., todo esto conlleva un tratamiento temporal que lo hace válido en un momento del tiempo, pero no siempre. En general los modelos adolecían de un verdadero tratamiento temporal acorde a la realidad Cosas sorprendentes Resolución de atributos multivaluados como Actor, Participantes, resueltos con una columna de 100 caracteres en los que se coloca la lista de actores, participantes, etc. Eso sencillamente es no seguir el modelo relacional. Espectáculos musicales en los que solo puede intervenir un intérprete. Me recuerda a aquel hospital en el que un enfermo no podía realizar un segundo ingreso en la misma cama. Y ya que se mencionaron muchas series, esto iría en la más pura línea de Carol Beer en Little Britain: Computer says no Detalles destacados Evidente muchos trabajos tienen detalles interesantes. Particularmente quisiera destacar la estructuración y la claridad que tiene el del grupo 12. 4

6 3. Consideraciones iniciales (otros cursos) 3.1. Notas Las valoraciones de cada parte de las prácticas se han establecido entre 0 y 5. En general, un trabajo normal que realiza lo solicitado, aunque presente algún error, se valora con un 3. Si el trabajo presenta aspectos destacables y tiene errores de menor importancia, puede llegar a un 4. El 5 se reserva para trabajos que destacan especialmente, por lo que es normal que casi no se logre esa valoración. En la parte 4, dado que se pedía algo más concreto, la valoración es de 1, 3 o 5, indicando que el trabajo es flojo, regular o bueno, respectivamente Problemas con Oracle Algunos estudiantes han comentado que la versión de Oracle presentaba diversos problemas, especialmente en el uso de Java. Lo que se nos había comunicado es que la versión instalada era la misma que el curso pasado, donde no hubo esos problemas, cuando realmente se trabalaba con una release posterior. Los detalles se pusieron en conocimiento de los responsables de mantener el producto y se dió algún día adicional para compensar por el tiempo perdido por esos detalles Tratamiento de las claves foráneas En el modelo relacional puro deben incluirse las acciones referenciales de las claves foráneas. En el paso a Oracle, deben mantenerse las que se puedan e indicar una manera de declarar las restantes, como disparadores, etc., aunque en esta práctica no fuera necesario crear los disparadores Nombrar las restricciones Conviene recordar que es aconsejable nombrar las restricciones, sobre todo las más comunes (c.p, NOT NULL, unicidad, etc.), evitando que el sistema use un nombre críptico Tratamiento de la integridad En el modelo relacional puro se debe realizar un tratamiento riguroso de la integridad, incluyendo las aserciones si son necesarias Trabajo en equipo Lo importante de la práctica es lo que el grupo aprende realizándola. Aunque cada miembro del grupo haga su parte de manera independiente, es necesario una exposición final conjunta de cada parte, con la consiguiente revisión, corrección y aceptación final del grupo, lo que aportará un conocimiento adicional. 5

7 3.7. Los dominios en el modelo relacional Los dominios en el modelo relacional, indican la naturaleza de un dato, pero no sólo lo obvio: tipo de dato, formato y conjunto de valores, sino también los aspectos semánticos de un dato, o sea, su significado. Por ese motivo si un dato es completamente similar a otro en todo menos en su significado, no pueden tener el mismo dominio. Por ejemplo, dos datos que provienen de un subrogado, como un número de cliente y un número de servicio, pueden tener absolutamente todo igual -tipo de dato, formato y conjunto de valores-, pero obviamente son datos diferentes, por lo que deben tener diferente dominio. Se suele usar de manera informal el criterio de comparación para determinar si dos datos tienen o no el mismo dominio: si dos datos son comparables, en el sentido de que pueden darse consultas que comparen cómo es uno frente al otro, entonces tendrán el mismo dominio, y no lo tendrán en otro caso. No parece muy necesario que se compare si un número de cliente es mayor que el de un servicio. Los dominios se indican al principio, justo después de la nomenclatura. Los fabricantes tienden a no incluirlos en sus productos, dado que los tipos de datos definidos por el usuario pueden realizar un papel similar Nomenclatura Hay que recordar un principio básico del trabajo con bases de datos: en una base de datos, los datos se almacenan orientados al propio dato, a la naturaleza del mismo, y no a cómo se utiliza, en qué aplicaciones interviene ni a cómo se almacena físicamente. Hacerlo de otra forma es no considerar el valor corporativo de un dato, que puede aparecer en múltiples aplicaciones, pero que debería almacenarse una única vez y con un único nombre que fuera conocido y reconocido en toda la organización. Aunque se utilizasen aplicaciones verticales, que tratan una temática determinada, los nombres de los datos deberían seguir una regla genérica para su formación. Recordad que no deben usarse homónimos ni sinónimos, como se comentó en clase. El nombre de un dato debe reflejar lo que significa el dato, y debe ser sencillo y claro. La sencillez se logra con normas simples, fáciles de recordar. El nombre del dato debe hacer referencia a la naturaleza del dato, no a cómo se usa ni en dónde aparece. Puede aparecer en el nombre de un atributo una referencia a la palabra primaria de la que deriva, como en nombre de empleado, nombre de servicio, etc., que indican la esencia del dato de forma clara, pero eso no implica que todos los atributos tengan que denominarse 6

8 con una referencia a la tabla en la que aparecen. El atributo debe determinar la naturaleza del dato, no en qué tabla aparece el dato, qué aplicación lo usa, etc. Debéis preguntaros las ventajas y los inconvenientes que eso tiene, aunque lo proponga el organismo que sea. En la propuesta realizada por alguna institución, como la indicada en la página web, algunas de sus decisiones son francamente mejorables. Se puso como ejemplo de lo que no debía de hacerse, como elemento a criticar. Concretamente la vinculación del nombre de la tabla con la aplicación, denota una escasa orientación a los datos y una gran orientación a las aplicaciones, eliminando el valor del dato como elemento corporativo, un error frecuente en la administración pública. La denominación de las claves foráneas, haciéndola depender de la tabla en la que se encuentran, es otro fallo importante VARCHAR2 de Oracle Oracle usa desde una versión anterior un tipo de datos VARCHAR2 que sustituye al antiguo VARCHAR, con el objetivo de ser más eficiente, manteniendo el tipo de dato antiguo por compatibilidad con las aplicaciones que ya lo usaban, pero recomendando la utilización del nuevo en los futuros desarrollos Resta de fechas (años de trabajo, edad actual) El tratamiento de fechas con Oracle es, al menos, laborioso, con funciones muy específicas, por lo que no se ha realizado una profundización en ellas. En la práctrica a entregar, no se recomienda el uso de consultas que exploten esas posibilidades, por no aportar elementos estructurales. De todas formas algunos preguntáis cuestiones sobre esto y os recuerdo que todo se soluciona usando las máscaras de formato y las funciones específicas de Oracle para el tratamiento de datos de tipo DATE, como SYSDATE, ADD_MONTHS, CURRENT_DATE, MONTHS_BETWEEN, etc., lo que lleva a consultas un poco laboriosas. Por ejemplo, para saber la edad actual de una persona o el tiempo en años, meses y días que un empleado lleva trabajando, podemos hacer: SELECT hiredate, TRUNC(MONTHS_BETWEEN(SYSDATE,hiredate)/12) anos, MOD(TRUNC(MONTHS_BETWEEN(SYSDATE,hiredate)),12) meses, TRUNC(SYSDATE - ADD_MONTHS(hiredate, (TRUNC(MONTHS_BETWEEN(SYSDATE,hiredate))))) FROM emp dias Colocación de las claves primaria y foráneas en una tabla Aunque nada impide que una clave primaria ocupe cualquier posición entre las columnas de una tabla, es una costumbre tácita colocar como primeras columnas las que forman la clave primaria y como últimas las claves foráneas. Esto se considera una buena práctica porque clarifica el papel que desempeñan las columnas, facilita la comprensión de las columnas de la tabla y evita errores. 7

9 Evidentemente en el caso en el que se tiene una columna que sea a la vez parte de una clave primaria y de una clave foránea, prevalece la posición determinada por la clave primaria Columnas de tipo DATE como parte de claves primarias o claves foráneas Ya se comentó en clase la dificultad que supone trabajar con tipos de datos DATE como claves primarias. Aunque no se puede considerar un error, casi nunca es una buena idea en el modelo relacional. Aunque en el EER puede ponerse y aceptarse, al pasar a relacional resulta que es un dato complicado de manejar, porque muchas veces en el mismo día ocurren varios eventos, con lo que el dato tendría que incluir las horas, minutos, segundos y entonces resulta muy poco adecuado para una clave primaria, pudiendo cambiarse por una clave primaria subrogada. Esto no contradice a lo expuesto en el modelo EER, porque en el modelo relacional pueden aparecer algunas columnas que no estaban necesariamente en el EER. 4. Errores frecuentes (otros cursos) Se han cometido diversos errores que se han observado en los trabajos, con diferente grado de importancia, que han tenido influencia en las notas obtenidas. Alguien puede pensar que en unas tablas se puede almacenar datos de cualquier manera, pero eso solo puede hacerlo quien opina desde la ignorancia de las características del modelo relacional y de sus posibilidades. Una persona con estudios de Ingeniería Informática debería ser capaz de entender y detectar si un modelo relacional es mejor que otro, a qué se deben las mejoras y las ventajas que conlleva. A lo largo del curso se intentó trasladar estas ideas, pero en algunos casos las prácticas caen en errores que parecen indicar que no se han entendido completamente. Entre los errores más destacados están los siguientes: 4.1. Redundancia Una base de datos se diseña para unas necesidades determinadas, pero teniendo en cuenta las ventajas genéricas que proporciona, como la eliminación de la redundancia, etc. Por este motivo no puede entenderse que datos completamente determinados, como provincia, país, etc, se almacenen de forma literal, como una columna más de una tabla, ya que eso es un caso flagrante de redundacia absurda que acabará generando inconsistencias, de manera que en esa columna aparezca, por ejemplo A Coruña, Coruña, La Coruña, Cruña. En estos detalles normalmente no se repara al realizar el ER, pero en el MR debe procederse creando una tabla adicional Incongruencias en la documentación Se exponen hechos contradictorios en diferentes partes de la documentación, por ejemplo se expresa en el diagrama del esquema relacional una cosa y otra incompatible con lo anterior más adelante. 8

10 4.3. Inadecuado trabajo en equipo En algunos casos da la sensación de que el trabajo se hizo por partes, esto es, cada miembro del grupo hizo su parte, pero en vez de una exposición final conjunta de cada parte, con la consiguiente revisión, corrección y aceptación final del grupo, sencillamente se entregó sin esa revisión final Errores en las restricciones No se diferencian las claves foráneas o no se indican a qué referencian. No incluir las acciones referenciales en las claves foráneas. Si se trata de una clave foránea compuesta, la referencia se hace individualmente para cada atributo que la forma. A veces esto ocurre solo en el dibujo y otras se traslada también a las sentencias. No se usa el MATCH cuando se necesita Usar los mismos nombres para columnas con significado diferente Además del error en sí mismo, normalmente conlleva que normalmente el dominio se unifique, cuando deberían ser distintos Uso de sinónimos Aparecen en varios trabajos, sobre todo en las claves foráneas. Además del error del sinónimo, conllevan otros problemas como dar lugar a equívocos, imposibilidad de utilización del NATURAL JOIN, generación de nombres de columnas muy extensos al repetirse una clave foránea por varias tablas, etc Dominios Los dominios en el EER permiten coincidir, por ejemplo, en un dominio para valores numéricos, pero en el modelo relacional, el dominio tiene una connotación semántica importante, que conlleva que los atributos pertenecientes al mismo dominio han de ser los directamente comparables, por lo que, por ejemplo, un dominio para el código de empleado y otro para el código de departamento, tiene sentido por ser valores no comparables. Para las personas escépticas en este punto, añadir que los dominios tienen como ventajas aplicar propiedades genéricas a todos los atributos que pertenecen a ellos y permitir determinar todos los atributos que tienen una naturaleza dada, y como consecuencia, establecer los datos que son directamente comparables, que son los pertenecientes al mismo dominio Nombres de claves foráneas al estilo balear Que el nombre de un atributo contenga el del dato del que deriva, se refiere a que, por ejemplo, al hablar de nombre de empleado, usemos un nombre que contenga algo referente a 9

11 nombre y algo acerca de empleado, pero ello no implica que se aplique a las claves ajenas, porque así estaríamos usando sinónimos, ni siquiera cuando estas claves ajenas forman parte de las claves primarias. El ejemplo del gobierno balear, era realmente un contraejemplo, como se comentó en clase. Por ejemplo: emp(cdgemp, nmbemp,..., cdgdpt) dpt(cdgdpt, nmbdpt) Pero en histórico de empleado no resulta lógico sustituir el nombre del código del empleado por algo indicativo de la tabla a la que pertenece, como por ejemplo: hst_emp(cdgemphstemp, nmrhstemp,...) sino usar directamente el nombre dado en la tabla empleado: hst_emp(cdgemp, nmrest,...) En general, las claves ajenas deben tener el mismo nombre que las candidatas a las que referencian, si representan realmente el mismo dato, aunque hay casos en los que esto último no ocurre y entonces la clave ajena no debe tener el mismo nombre. Por ejemplo, en la tabla empleado el código del departamento al que pertenece, representa justamente el dato código de departamento de la tabla departamento, por lo que debe tener el mismo nombre: emp(cdgemp, nmbemp,..., cdgdpt) dpt(cdgdpt,...) Pero si en la tabla departamento incluimos el código del empleado que es director del departamento, ese director, aún siendo un empleado, no se refiere a cualquier empleado, sino solo a los que son directores, por lo que aquí sí que sería más adecuado usar un nombre de atributo diferente, por ejemplo cdgdrc para el director: emp(cdgemp, nmbemp,..., cdgdpt) dpt(cdgdpt,..., cdgdrc) Hay casos determinados donde no es posible seguir la norma, por ejemplo si dos subclases del mismo tipo de entidad tienen un tipo de relación N:M entre ellas. En este caso es mejor asignar un nombre diferente a los atributos de las relaciones en la que se convierten las subclases y mantenerlo en la relación que deriva del tipo de relación N:M Representación gráfica de las claves foráneas compuestas Respecto a la representación gráfica de las referencias de las claves foráneas compuestas, se penalizó las referencias de cada atributo individual, ya que además de un grave error origina que la gráfica sea equívoca. 10

12 4.10. Incluir en un CHECK una lista extensa de valores Se comentó en clase lo anacrónico que resulta esto, lo que impide destacar la importancia de los valores de los datos y lo que dificulta la programación. (Relacionada con 4.1 en la página 8). En algún caso, el error se reiteró en una tabla auxiliar que precisamente se utiliza para evitarlo Vinculaciones mal representadas en el esquema relacional La transformación de las cardinalidades del ER al pasarlas al MR es como sigue: Una cardinalidad 1:N en el ER se convierte en una vinculación 1 a muchos en el MR. Una 1:1 en ER pasa como 1 a 1 al MR. Una N:M en el ER necesita de dos vinculaciones 1 a muchos en el MR. Este sencillo planteamiento no se sigue en varios trabajos, sobre todo en la representación del esquema relacional, haciendo que el dibujo sea incorrecto. En varios casos una cardinalidad 1:1 se representa mal en el MR. Hay dos casos particulares importantes. El primero es el de las subclases, que poseen una cardinalidad 1:1 con relación a la superclase de la que proviene y que se sobreentiende en el diagrama ER, por lo que al pasar a relacional debe dibujarse como 1 a 1 y no como 1 a infinito. En el caso de una categoría la cardinalidad también es 1:1 y ocurre lo mismo al pasar a relacional. La herramienta MySQL Workbench permite representar adecuadamente las vinculaciones 1 a 1 (pulsar sobre la vinculación, elegir la pestaña Foreign Key, seleccionar One-to-one) Subclase con tipo de relación 1:N o N:M fusionada con la superclase Este detalle se comentó en clase con la antelación necesaria para corregirlo por lo que se consideró erróneo. Aunque pueda pensarse que es válido hacerlo, origina un modelo menos robusto que requiere la incorporación de condiciones de comprobación adicionales. La condición de clave foránea está completamente ligada a la integridad referencial, que es una de las características más importantes del modelo relacional. Al actuar de esta forma se tergiversa la integridad referencial porque una clave foránea realmente no referencia a una columna sino solo a unas filas de esa columna. La situación es inevitable en el caso de trasladar subclases y categorías, pero constituye una mala práctica en otras situaciones en las que es completamente evitable. El objetivo debe ser que el MR recoja en lo posible las condiciones de los datos, por lo que si lo hace será un diseño robusto, y si no lo hace será menos robusto y necesitará condiciones adicionales. Si se opta por un modelo menos robusto por seguir una elección entre varias, se están haciendo las cosas un poco peor de lo que podrían hacerse. 11

13 4.13. Pasar una categoría al modelo relacional de forma errónea Un error que resulta extraño pero que se ha producido Consultas SQL En general los errores aquí fueron por usar sentencias relativamente sencillas en su construcción, o que solicitaban cosas muy simples, o que desarrollaron un esquema determinado, aunque fuera complejo, pero que se repitieron de forma reiterada. Sobre este punto conviene recordar que se tuvo en cuenta, entre otras cosas, lo realizado por los diferentes grupos, esto es, se determinaron las valoraciones también por las diferencias que se presentaban entre unos trabajos y otros Reducida capacidad de explicación y de claridad En varios trabajos se observó una reducida capacidad en las explicaciones de las opciones elegidas o una falta de claridad en la exposición de argumentos. 5. Otros detalles importantes Como no se habló estrictamente de ello en las clases, conviene mencionar algo acerca de la influencia de las normas legales en el diseño, especialmente en el caso de la Ley Orgánica de Protección de Datos Diseño acorde a la LOPD La influencia de las normas legales puede ser muy importante en el diseño de una base de datos. El marco regulatorio impuesto por la LOPD -ley orgánica de protección de datos es algo que debe tenerse en cuenta, aunque supere los objetivos de la asignatura. La utilización de datos personales debe ser acorde a los derechos plasmados en la LOPD, entre ellos la rectificación y la cancelación, por lo que por ejemplo el uso de un DNI como clave primaria dificulta la adecuación a los requerimientos de la LOPD. Por otra parte, esto confirma lo ya comentado acerca de la inconveniencia de utilizar en un sistema de información propio, identificadores externos como el DNI, por arrastrar con ello a nuestro sistema los errores que ese identificador externo conlleva. EL DNI es un dato que supone un criterio de búsqueda muy utilizado, pero una cosa es eso y otra utilizarlo como identificador. 12