Comentarios sobre las prácticas y los errores más frecuentes

Prácticas de Bases de Datos 2 – EI, MI – 2010-2011
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
Contenido
1.
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.
Errores habituales de este curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.
4.
2.1.
Redundancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2.
Atributos que forman parte de las claves primarias . . . . . . . . . . . . . . . . . . . .
4
2.3.
Índices propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4.
MATCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.5.
Modelo que prescinde del planteamiento temporal . . . . . . . . . . . . . . . . . . . .
4
2.6.
Cosas sorprendentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.7.
Detalles destacados
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Consideraciones iniciales (otros cursos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1.
Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2.
Problemas con Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.3.
Tratamiento de las claves foráneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.4.
Nombrar las restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.5.
Tratamiento de la integridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.6.
Trabajo en equipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.7.
Los dominios en el modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.8.
Nomenclatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.9.
VARCHAR2 de Oracle
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.10. Resta de fechas (años de trabajo, edad actual) . . . . . . . . . . . . . . . . . . . . . .
7
3.11. Colocación de las claves primaria y foráneas en una tabla . . . . . . . . . . . . . . . .
7
3.12. Columnas de tipo DATE como parte de claves primarias o claves foráneas . . . . . . .
8
Errores frecuentes (otros cursos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.1.
Redundancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.2.
Incongruencias en la documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.3.
Inadecuado trabajo en equipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.4.
Errores en las restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.5.
Usar los mismos nombres para columnas con significado diferente . . . . . . . . . . . .
9
4.6.
Uso de sinónimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.7.
Dominios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.8.
Nombres de claves foráneas al estilo “balear” . . . . . . . . . . . . . . . . . . . . . . .
9
4.9.
Representación gráfica de las claves foráneas compuestas . . . . . . . . . . . . . . . . .
10
4.10. Incluir en un CHECK una lista extensa de valores . . . . . . . . . . . . . . . . . . . .
11
4.11. Vinculaciones mal representadas en el esquema relacional . . . . . . . . . . . . . . . .
11
4.12. Subclase con tipo de relación 1:N o N:M fusionada con la superclase . . . . . . . . . .
11
1
5.
4.13. Pasar una categorı́a al modelo relacional de forma errónea . . . . . . . . . . . . . . . .
12
4.14. Consultas SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.15. Reducida capacidad de explicación y de claridad . . . . . . . . . . . . . . . . . . . . .
12
Otros detalles importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
5.1.
Diseño acorde a la LOPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
12
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 5.
2.
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
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.
2.3.
Í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.
2.4.
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.
2.5.
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.
2.6.
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”.
2.7.
Detalles destacados
Evidente muchos trabajos tienen detalles interesantes. Particularmente quisiera destacar la
estructuración y la claridad que tiene el del grupo 12.
4
3.
3.1.
Consideraciones iniciales (otros cursos)
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.
3.2.
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.
3.3.
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.
3.4.
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.
3.5.
Tratamiento de la integridad
En el modelo relacional puro se debe realizar un tratamiento riguroso de la integridad,
incluyendo las aserciones si son necesarias.
3.6.
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
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.
3.8.
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
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.
3.9.
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.
3.10.
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))))) dias
FROM
emp
3.11.
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
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.
3.12.
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.
4.2.
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
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.
4.4.
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.
4.5.
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.
4.6.
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.
4.7.
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.
4.8.
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
“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.
4.9.
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
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.
4.11.
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).
4.12.
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
4.13.
Pasar una categorı́a al modelo relacional de forma errónea
Un error que resulta extraño pero que se ha producido.
4.14.
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.
4.15.
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.
5.1.
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
http://www.boe.es/boe/dias/1999/12/14/pdfs/A43088-43099.pdf- 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