2009-06-26 12 views
7

Una vista SQL es una tabla global y lógica que puede o no ser persistente. Pero sigue siendo una mesa. Por lo tanto, ¿debe una VISIÓN siempre adherirse a la primera forma normal (1NF)? es decir, no hay filas duplicadas, solo tipos escalares, no ordena de arriba hacia abajo o de izquierda a derecha, etc. ¿Qué pasa con las formas normales más altas?¿Debería una SQL VIEW estar siempre en 1NF?

Para mí, mis aplicaciones 'consumen' los resultados de los procesos almacenados, mis VIEW son 'consumidas' por consultas SQL, y estos dos usos son mutuamente excluyentes (es decir, no consulto los conjuntos de resultados de los procesos almacenados usando SQL y mis aplicaciones no contienen código SQL). He visto a otros usar una VISTA para 'concatenar' múltiples valores en una columna en una sola fila, generalmente en formato separado por comas. Escribir predicados en una consulta SQL contra una columna de este tipo requiere un kludges similares a esta:

',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%' 

Por lo tanto, me parece razonable esperar que todas las tablas que se pueden consultar a consistir sólo los tipos escalares. ¿Estoy siendo demasiado "purista" al pensar esto?

Respuesta

3

Tiene mucho sentido asegurar que sus vistas estén normalizadas a por lo menos 1NF. Permitir duplicados, por ejemplo, tiene la desventaja de que el significado de la vista se vuelve ambiguo y los usuarios pueden identificar erróneamente la información. Se pueden producir datos incorrectos si las tablas se actualizan en función de dichas ambigüedades.

E.F.Codd no necesariamente estuvo de acuerdo. En su libro de la versión 2 de RM, propone vistas sin teclas, un gran error, creo. Las vistas de Codd en realidad no permiten duplicados pero sí permiten que cada columna sea nulable y, por lo tanto, no tienen claves y no están en 1NF.

Un valor de cadena que contiene una lista delimitada por comas no es en sí una violación de 1NF. Un valor de cadena es un escalar como cualquier otro valor, sea lo que sea que contenga. La mayoría de los DBMS SQL no permiten atributos multivalor.

9

No, creo vistas para que coincidan con los resultados que requiere mi programa.

+0

Mi opinión ha sido 'consumido' por sólo consultas SQL. Si mi programa necesita un conjunto de resultados en un formato 'especial', entonces lo haría en un proceso almacenado o en el nivel medio. No estoy sugiriendo que la salida de cada proceso almacenado deba estar en 1NF, solo que la salida sea en forma de * tabla * (y supongo que eso incluiría variables de tabla cuando corresponda). – onedaywhen

+0

Obviamente, ha creado reglas para su propia aplicación (sin SQL en los clientes, por ejemplo) que le resulten útiles. Son más restrictivos de lo que consideraría mejores prácticas, pero lo bueno de ser demasiado restrictivo es que siempre es fácil cambiar de opinión más adelante y estar más relajado, no tan fácil de ir para el otro lado. Pero en general, el resultado de las vistas puede violar 1NF (aunque las filas dupe son inútiles, AFAIK). De hecho, el uso de vistas desagradables es una de las mejores formas de migrar un diseño feo a un diseño limpio: necesita las vistas para admitir clientes heredados hasta que también puedan corregirse. –

4

El objetivo de los sistemas relacionales es mantener los datos en relaciones normalizadas para la eficiencia y/o la capacidad de administración, y luego usar los operadores relacionales para convertirlos en las relaciones que necesita.

Una vista no materializada no se almacena, es una consulta.

Es por eso que debe crearlo en la forma que mejor se adapte a sus necesidades de aplicaciones.

Consulte this answer para obtener más información.

1

No creo que esto sea una regla, pero si lo fuera - No se debería seguir ninguna regla siempre.

+1

Creo que el enfoque aceptado es que sigas las 'reglas' de normalización y luego sigas las 'reglas' de desnormalización si hay buenas razones para hacerlo. A menos que seas un anarquista, en cuyo caso las reglas son que no hay reglas, lucha contra el poder, los pantalones de esclavitud, felicitaciones para ti. – onedaywhen

0

una vista (a menos que se materializó/vista indizada) no es más que una consulta almacenada Vistas pueden contener más de una tabla, pueden tener uno mismo se une a la misma mesa, etc, etc

+0

De hecho, y puedo unirme a una tabla vista (a.k.a. VISTA) a otras tablas ... por lo que realmente sería útil si todas las columnas son de tipo escalar. – onedaywhen

+0

... Agregué una descripción de este uso y las implicaciones para 1NF en mi pregunta. – onedaywhen

-2

n - normalización reglas se aplican a la persistencia de los datos, no la presentación de los mismos Por ejemplo, cualquier fila duplicada en una vista rompería 1NF, lo que obviamente es demasiado restrictivo.

Para obtener más información, consulte First normal form.

+0

¿Cómo es útil una VISTA con filas duplicadas? ¿Tienes un ejemplo de la vida real en mente? Gracias. – onedaywhen

+0

¿Por qué el voto a favor? – RedFilter

+0

No respondes a mi pregunta educada pero esperas una respuesta a la tuya? ;) Sin embargo, el voto a favor no fue mío. – onedaywhen

0

Según Chris fecha, puntos de vista deben ser plenamente normalizado:

La elección en cuanto a que las relaciones de hacer las bases, y que los puntos de vista, es arbitraria. Como ejemplo trivial, es posible que tenga empleados y que tenga una relación de base que contenga a todos los empleados, y es posible que tenga Empleados de la Costa Este y Empleados de la Costa Oeste como dos puntos de vista. O bien, puede tener a los empleados de la Costa Este y Costa Oeste como dos relaciones de base, y derivar la unión de todos ellos como una vista. Es completamente arbitrario.

Entrevista con Chris DBMS Fecha - Octubre de 1994

Cuestiones relacionadas