Durante el diseño de las tablas en SQL Server, vemos que

Transcripción

1 1. VALORES PREDETERMINADOS Durante el diseño de las tablas en SQL Server, vemos que principalmente tenemos que hacer dos cosas: crear las columnas que las constituyen (indicando el tipo de datos de cada una de ellas) y establecer su clave principal. Después, cuando comprobamos que necesitamos algo más para poder extraer resultados útiles de la información almacenada en la base de datos y para mantener su integridad, establecemos las correspondientes relaciones o restricciones de clave externa. SQL permite afinar todavía más el diseño de las tablas, incluyendo conceptos que nos permiten representar lo más fielmente posible la naturaleza de la información que en ellas se almacena. Valores predeterminados, restricciones de valor, restricciones de unicidad, etc. hacen que la base de datos incluya por sí misma cierta lógica y no sólo datos. Como resultado de todo esto, tendremos que la propia base de datos se encargará de comprobar y exigir la coherencia de la información almacenada independientemente de la aplicación que interactúa con ella. Una característica que podemos establecer siguiendo este razonamiento es incluir el valor predeterminado de las columnas o campos de una tabla, que no es más que el valor que se insertará en el campo si no se indica ninguno. El valor predeterminado debe ser acorde al tipo de datos de la columna. Por ejemplo, fíjese que uno de los campos de la tabla Productos es ImageURL, donde se indica la ubicación y nombre de una pequeña imagen representativa del producto. Copyright Computer Aided Education, S.A. 1

2 Podríamos preparar una imagen genérica para los casos en que no se disponga de ninguna imagen particular del producto. Pues esa imagen puede ser el valor predeterminado de este campo. El valor predeterminado de un campo se establece en la propiedad Valor o enlace predeterminado. El valor predeterminado puede ser tanto una constante como una expresión, pero debe ser de un tipo acorde al tipo de datos del campo de la tabla. En el ejemplo anterior, es la cadena de caracteres 'sinfoto. gif', por lo que debe incluirse entre comillas simples. Es decir, que si no se indica una imagen particular, cada producto tendrá la imagen sinfoto.gif por defecto. Si el campo fuera numérico, incluiríamos un número; si fuera de tipo fecha y hora, una fecha correcta. Por ejemplo, vamos a establecer la fecha actual como valor predeterminado del campo FechaOrden de la tabla Ordenes. Podemos utilizar una expresión para obtener el valor predeterminado. Lo importante es que esa expresión se evalúe a un valor correcto para el campo en cuestión. Obsérvelo en la figura siguiente. 2

3 En este caso, con la función GETDATE obtenemos la fecha y hora actual. Por lo tanto, cuando se cree una orden tendrá como fecha la de ese momento. Esto no quiere decir que no podamos insertar un valor distinto. Aunque un campo tenga valor predeterminado, siempre podremos insertar uno distinto. La cuestión es que si no lo hacemos, tendrá el valor predeterminado. 2. RESTRICCIONES CHECK Otra característica asociada con una columna que podemos utilizar son las restricciones de valor o restricciones Check. El concepto es parecido al de las restricciones de integridad referencial, ya que estas últimas restringen el valor que pueden tener ciertas columnas a los valores almacenados en otra columna de una tabla distinta (un producto debe tener una categoría existente en la tabla Categorias, por ejemplo). Las restricciones Check son parecidas a esto pero los valores que puede albergar una columna de tabla no hacen referencia a otra columna de otra tabla, sino a un conjunto de valores conocidos y establecidos directamente en la restricción. Con un ejemplo se ve todo más claro. Fíjese en la estructura de la tabla Ordenes. Vemos que para cada orden nos guardamos tanto la fecha de expedición de la orden (campo FechaOrden) como la fecha real del envío de la orden (FechaEnvio). Copyright Computer Aided Education, S.A. 3

4 Como ambos campos son del tipo datetime, pueden albergar cualquier fecha/hora correcta. Pero, tiene sentido que la fecha de envío de la orden sea posterior a la fecha de expedición? Claramente no, ya que no deberíamos permitir que se guarde una fecha de envío posterior a la fecha en la que realmente se crea la orden. Para establecer esta restricción, debemos utilizar una restricción Check. Podemos hacerlo de dos formas, desplegando el contenido de la tabla en el panel de la izquierda y crear una restricción Check con el menú contextual de la carpeta Restricciones o pulsar directamente el botón Administrar restricciones Check en el modo de diseño de la tabla. En ambos casos accederemos a un cuadro de diálogo como el de la figura siguiente donde deberemos definir la restricción. Lo primero es pulsar en el botón Agregar y después utilizar la propiedad Expresión. Fíjese que en la definición de la restricción podemos utilizar campos de la tabla, no es necesario que sean únicamente valores literales, como un valor numérico o una cadena de texto. 4

5 Como tanto FechaOrden y FechaEnvio son de tipo datetime, podemos compararlos entre ellos. Ésta es una de las ventajas de representar las fechas con este tipo de datos y no como cadenas de caracteres. Si desea deshabilitar temporalmente una restricción Check, establezca a No la propiedad Exigir para INSERTs y UPDATEs. Esto puede ser necesario, por ejemplo, cuando se importan datos provenientes de otra base de datos donde la información puede no respetar la restricción establecida. Adicionalmente, con la propiedad Comprobar datos existentes podremos indicar si queremos aplicar la restricción incluso para los datos que ya pudieran almacenarse en la tabla. Además de hacerlo siempre que se inserte un nuevo registro o se actualice alguno de los existentes (propiedad Exigir para INSERTs y UPDATEs). Finalmente, puede establecer el nombre y la descripción de la restricción. Normalmente las restricciones Check empiezan con el prefijo CK pero después nosotros podemos poner el nombre que queramos para identificarlas. Veamos otro ejemplo de restricción Check. Vamos a exigir que la dirección de correo electrónico que ntroduce cada cliente tiene que incluir siempre el carácter arroba (@). Fíjese cómo hacerlo en una restricción Check para el campo de la tabla Clientes. La expresión utilizada en este caso es: CHARINDEX('@', ) <> 0 Copyright Computer Aided Education, S.A. 5

6 Utilizamos la función CHARINDEX, que devuelve la posición inicial de una expresión en una cadena de caracteres. Nosotros buscamos el carácter en el campo . La restricción comprueba que la posición inicial de este carácter sea distinto de cero; es decir, que exista el carácter arroba en el valor del campo . En resumen vemos que las restricciones Check permiten introducir restricciones o limitaciones de sentido común en la propia definición de la tabla. Al guardarlas como parte de la tabla, es SQL Server el que se encarga de aplicarlas cuando se insertan nuevos registros o cuando se actualizan los existentes, por lo que nuestras aplicaciones no tienen que preocuparse de ello. Otros ejemplos de restricciones Check que podríamos utilizar en nuestra base de datos: - CodPostal LIKE '[0-9][0-9][0-9][0-9][0-9]': para exigir que el código postal esté compuesto únicamente por 5 dígitos. - Cantidad > 0: para exigir que la cantidad comprada de un producto en cierta orden sea siempre positiva. - Edad BETWEEN 18 AND 120: La edad de los clientes tiene que estar entre los 18 y 120 años. En resumen, podemos utilizar constantes, funciones y operadores del lenguaje propio de SQL Server, conocido como T-SQL. 3. RESTRICCIONES UNIQUE Cuando se estudia la forma de establece la clave principal de una tabla, se indica que, de esta forma, cada registro se identifica unívocamente, ya que no puede haber valores repetidos para la clave principal. Las restricciones UNIQUE son parecidas en este aspecto, ya que no permiten que en un campo haya valores repetidos, pero se diferencian de las claves principales en que sí que pueden admitir valores NULL. 6

7 Además, podemos definir varias restricciones UNIQUE en una tabla, pero ésta sólo podrá tener una clave principal (compuesta por uno o más campos). Por lo tanto, podemos utilizar restricciones UNIQUE para garantizar que no se introducen valores duplicados en campos que no forman la clave principal de la tabla. Por ejemplo, en la tabla Clientes podría tener sentido garantizar que los clientes no introducen direcciones de correo electrónico repetidas. Para ello, podríamos incluir una restricción UNIQUE en el campo . Para crear una restricción UNIQUE, acceda a la estructura de la tabla y pulse en el botón Administrar índices y claves de la barra de herramientas y accederá a un cuadro de diálogo como el de la figura siguiente, donde ya se ha definido la restricción IX_Clientes_1. Lo primero es pulsar en el botón Agregar y después indicar qué columna "sufrirá" la restricción. En la figura anterior vemos que es la columna . Adicionalmente, debemos indicar, en la propiedad Tipo, que se trata de una clave Unique. El nombre de las restricciones UNIQUE empieza siempre por IX. Tenga en cuenta que, aunque se permiten valores NULL con una restricción UNIQUE, sólo podrá almacenarse un valor NULL en este campo. Copyright Computer Aided Education, S.A. 7

8 Como la restricción UNIQUE no permite valores duplicados, tampoco permite que se guarde más de un NULL en el campo. 4. INTERCALACIÓN Otro aspecto importante a la hora de diseñar una tabla y, sobre todo, respecto de la información en forma de cadena de caracteres que almacena, es la intercalación o collation en inglés. La intercalación establece cómo se comparan y ordenan la información de texto de la base de datos. Como tal, podemos establecer la intercalación a distintos niveles: a nivel del servidor, a nivel de la base de datos, a nivel de la tabla e incluso a nivel de un campo o expresión. Recuerde que los tipos de datos Unicode empiezan por n y tienen el mismo nombre que los no Unicode: nchar, nvarchar, ntext... La contrapartida a utilizar tipos de datos Unicode es que cada carácter ocupa el doble que uno no Unicode. Como regla general, debemos utilizar la misma intercalación en toda la organización, de forma que no sean necesarias conversiones de intercalación cuando trabajemos con información proveniente de distintas bases de datos. Además, si es posible, deberíamos elegir siempre tipos de datos Unicode, ya que, al utilizar Unicode, todo esto se simplifica muchísimo porque siempre se utiliza la misma página de caracteres, independientemente del idioma de la aplicación que accede a la base de datos. Si la base de datos sólo va a ser utilizada por alguna aplicación en la que se utilizará un único idioma, es adecuado utilizar tipos de datos no Unicode, pero tampoco es mala idea utilizar Unicode porque en un futuro esto podría cambiar. Veamos con un ejemplo en qué condiciones podría interesarnos todo esto. Fíjese en el campo password de la tabla Clientes. En él se almacenará el password o contraseña que necesita el usuario para identificarse en la tienda virtual y poder realizar así un pedido. Normalmente, en la contraseña se tiene en cuenta la combinación de mayúsculas y minúsculas utilizada e incluso si se ha incluido algún acento. 8

9 Esto lo podemos indicar en su propiedad Intercalación. Inicialmente, se indica que se está utilizando la misma intercalación que la de la base de datos. De hecho esto se estableció durante la instalación de SQL Server y, por defecto, se utiliza la intercalación elegida en aquel momento para el servidor. Pulsando en el botón con tres puntos suspensivos que aparece al situarse en esta propiedad, accederá a un cuadro de diálogo como el de la figura. Copyright Computer Aided Education, S.A. 9

10 Aquí podemos configurar las características de intercalación para el campo Password. Fíjese que lo estamos haciendo a nivel de columna, por lo que sólo afectará a la información almacenada en dicho campo. Por ejemplo, podríamos seleccionar el orden binario, con lo que cualquier carácter es distinto a cualquier otro que no sea exactamente el mismo; es decir, que distingue entre mayúsculas, minúsculas, letras acentuadas, etc. O podríamos seguir utilizando el orden de diccionario, pero estableciendo alguna característica adicional, como la sensibilidad para mayúsculas/minúsculas o letras acentuadas. En cualquier caso, recuerde la conveniencia de utilizar tipos de datos Unicode en escenarios de aplicaciones multiidioma o internacionales. Cuando utiliza cadenas de caracteres Unicode, debe anteponer a la cadena un N mayúscula. Por ejemplo, N'Hucha' es una cadena válida Unicode. Si no incluye la N, entonces se transformará a la página de códigos del servidor, aunque se guarde en un campo de tipo Unicode. Por otra parte, puede obtener la sintaxis correcta del comando CREATE TABLE o ALTER TABLE en la colección de documentación Libros de pantalla de SQL Server. Estos comandos T-SQL son los que se utilizan para crear/ modificar tablas sin una herramienta visual como SQL Server Management Studio. 10