Microsoft SQL Server 2008 Manual de Referencia

Capítulo 1
Sistemas de base de datos

relacionales: introducción
En este capítulo
▲
Sistemas de bases de datos:

descripción
▲
Sistemas de bases de datos

relacionales
▲
Diseño de bases de datos

▲
Convenciones de sintaxis
Copyright © 2010. McGraw-Hill Interamericana. All rights reserved.
Petkovic, D. (2010). Microsoft sql server 2008 : Manual de referencia. Retrieved from http://ebookcentral.proquest.com
Created from senavirtualsp on 2020-04-27 15:49:13.
4 Microsoft SQL Server 2008. Manual de referencia
E ste capítulo describe sistemas de bases de datos en general. Primero analiza lo que
es un sistema de base de datos y qué componentes contiene. Cada componente se
describe de forma breve, con una referencia al capítulo en el cual se estudia con de-
talle. La segunda sección importante del capítulo está dedicada a sistemas de bases de datos
relacionales. Analiza las propiedades de estos sistemas y el lenguaje correspondiente que se
utiliza en ellos [Structured Query Language (SQL)].
En general, antes de implementar una base de datos, tiene que diseñarla con todos sus
objetos. La tercera sección principal del capítulo explica cómo puede usar formas normales
para destacar el diseño de su base de datos, y también presenta el modelo de relaciones de
entidades, que puede usar para conceptualizar todas ellas y sus relaciones. La sección final
presenta las convenciones de sintaxis que se utilizan en todo el libro.
Sistemas de bases de datos: descripción

Un sistema de base de datos es una colección completa de diferentes componentes de soft-
ware de base de datos y bases de datos que contienen las partes siguientes:
Programas de aplicación de bases de datos

Componentes cliente
Servidor(es) de bases de datos
Bases de datos
Un programa de aplicación de base de datos es software de uso especial diseñado e

implementado por usuarios, o bien implementado por alguna compañía de software. En

contraste, los componentes cliente son software de base de datos de uso general diseñado e
implementado por una compañía de bases de datos. Mediante el uso de componentes cliente,
los usuarios pueden acceder a datos almacenados en la misma computadora o en una remota.
La tarea de un servidor de bases de datos consiste en manejar datos almacenados en
una base de datos. Cada cliente se comunica con un servidor de bases de datos y le envía
consultas del usuario. El servidor procesa cada consulta y devuelve el resultado al cliente.
En general, una base de datos se puede apreciar desde dos perspectivas: la del usuario y
la del sistema de base de datos. Los usuarios ven una base de datos como una colección de
datos ordenados de manera lógica. En el caso de un sistema de base de datos, una base
de datos es simplemente una serie de bytes, en general almacenados en un disco. Aunque
estas dos perspectivas de una base de datos son totalmente diferentes, tienen algo en común:
el sistema de base de datos necesita proporcionar no sólo interfaces que permitan a los
usuarios crear bases de datos y recuperar o modificar datos, sino también componentes del
Capítulo 1: Sistemas de base de datos relacionales: introducción 5
sistema para manejar los datos almacenados. Por lo tanto, un sistema de base de datos debe
contar con las siguientes características:
Variedad de interfaces de usuario

Independencia de datos físicos
Independencia de datos lógicos
Optimización de consultas
Integridad de datos
Control de concurrencia
Copia de seguridad y recuperación
Seguridad de las bases de datos
Las siguientes secciones describen estas características brevemente.

La mayoría de las bases de datos son diseñadas e implementadas para que sean utilizadas por
muchos tipos de usuarios con distintos niveles de conocimiento. Por esta razón, un sistema
de base de datos debe ofrecer muchas interfaces de usuario que incluyen, entre otras carac-
terísticas, menús y formas para usuarios finales, así como un lenguaje de consulta interactivo
para usuarios avanzados.

Independencia de datos físicos significa que los programas de aplicación de bases de da-
tos no dependen de la estructura física de los datos almacenados en ellas. Esta importante
característica le permite hacer cambios a los datos almacenados sin tener que hacer cam-
bios a programas de aplicación de bases de datos. Por ejemplo, si los datos almacenados se
ordenan previamente con base en un criterio, y se cambia este orden mediante el empleo de
otro criterio, la modificación de los datos físicos no debe afectar a las aplicaciones de bases de
datos existentes o al esquema de éstas (una descripción de una base de datos generada por el
lenguaje de definición de datos del sistema de base de datos).

En el procesamiento de archivos (durante el cual se emplean lenguajes de programación
tradicionales), la declaración de un archivo se realiza en programas de aplicación, de modo
que cualquier cambio a la estructura de ese archivo suele requerir la modificación de todos
los programas que lo utilizan. Los sistemas de bases de datos ofrecen independencia de
datos lógicos, es decir, es posible hacer cambios a la estructura lógica de las bases de datos sin
tener que hacer cambios a los programas de aplicación de ellas. Por ejemplo, si en el sistema
de base de datos existe la estructura de un objeto llamado PERSONA y desea agregarle un
atributo (por ejemplo, el domicilio), tiene que modificar sólo la estructura lógica de la base
de datos y no los programas de aplicación existentes.
Todo sistema de base de datos contiene un subcomponente llamado optimizador que
considera diversas estrategias de ejecución posibles para consultar los datos y luego selecciona
la más eficiente. La estrategia que selecciona se conoce como plan de ejecución de la consulta.
El optimizador toma sus decisiones con base en aspectos tales como el tamaño de las tablas
que participan en la consulta, qué índices existen y qué operador booleano (AND, OR o
NOT) se utiliza en la cláusula WHERE. (Este tema se analiza con detalle en el capítulo 20.)
Integridad de datos
Una de las tareas de un sistema de base de datos es identificar datos lógicamente incoheren-
tes y rechazar su almacenamiento en ella. (La fecha 30 de febrero y la hora 5:77:00 p.m. son
dos ejemplos de estos datos). Además, la mayoría de los problemas reales que se implemen-
tan mediante sistemas de base de datos tienen restricciones de integridad que se deben cumplir
con respecto a los datos. (Un ejemplo de una restricción de integridad podría ser el número
de empleado de la compañía, que debe ser un entero de cinco dígitos.) La tarea de mante-
ner la integridad la puede sortear el usuario en programas de aplicación o bien el DBMS
(sistema de manejo de bases de datos). Hasta donde sea posible, esta tarea la debe realizar el
DBMS. (La integridad de datos se analiza en dos capítulos de este libro: integridad declara-
tiva, en el capítulo 5, e integridad procesal [o de procedimientos], en el capítulo 14.)
Un sistema de base de datos es una estructura de software multiusuario, lo que significa que
muchas aplicaciones de los usuarios acceden a una base de datos al mismo tiempo. Por lo
tanto, cada sistema debe tener algún tipo de mecanismo de control que asegure que varias
aplicaciones que intentan actualizar los mismos datos lo hagan de forma controlada. El que
sigue es un ejemplo de un problema que puede presentarse si un sistema de base de datos no
contiene estos mecanismos de control:
1. Los titulares de la cuenta bancaria 4711 del banco X tienen un saldo de 2 000.
2. Los dos titulares mancomunados de esta cuenta bancaria, la Sra. A y el Sr. B, se forman
ante diferentes cajeros y cada quien retira 1 000 al mismo tiempo.
3. Después de realizar estas transacciones, la cantidad de dinero que hay en la cuenta
bancaria 4711 debe ser 0 y no 1 000.
Todos los sistemas de bases de datos cuentan con los mecanismos necesarios para sortear
casos como este ejemplo. El control de concurrencia se analiza con detalle en el capítulo 13.

Un sistema de base de datos debe tener un subsistema que se encargue de eliminar los erro-
res que cometen el hardware o el software. Por ejemplo, si ocurre una falla mientras una apli-
cación de base de datos actualiza 100 filas de una tabla, el subsistema de recuperación debe
volver a implementar todas las actualizaciones ejecutadas con anterioridad para asegurar que
los datos correspondientes sean coherentes después de que ocurre el error. Lea el capítulo 17
para tener una exposición más a fondo del proceso de copia de seguridad y recuperación.
Seguridad de bases de datos

Los más importantes conceptos de seguridad de bases de datos son la autenticación y la
autorización. Autenticación es el proceso de validación de las credenciales del usuario para
evitar que personas no autorizadas utilicen el sistema. La forma más común de reforzar la
autenticación se basa en la exigencia que debe satisfacer el usuario de ingresar un nombre (de
usuario) y una contraseña. Esta información la evalúa el sistema para determinar si el usuario
tiene permiso para acceder al sistema. Este proceso se puede reforzar mediante encriptación.
Autorización es el proceso que se aplica después de que se autentica la identidad de un
usuario. Durante esta etapa, el sistema determina qué recursos puede usar este usuario. En
otras palabras, la información estructural y del catálogo del sistema sólo está disponible para
usuarios principales que tienen permiso para acceder a esa entidad. (En el capítulo 12 se
analizan estos conceptos con detalle.)
Sistemas de bases de datos relacionales

Un componente de Microsoft SQL Server, llamado motor de base de datos, es un sistema de
base de datos relacional. La noción de los sistemas de bases de datos relacionales fue intro-
ducida por vez primera por E. F. Codd en su artículo “A Relational Model of Data for Large
Shared Data Banks” en 1970. En contraste con sistemas de base de datos anteriores (de red y
jerárquicos), los sistemas de bases de datos relacionales se basan en el modelo de datos relaciona-
les, que tiene un sólido antecedente matemático.
NOTA
Un modelo de datos es una colección de conceptos, sus relaciones y sus restricciones que se utilizan para representar
datos de un problema real.
El concepto central del modelo de datos relacionales es una relación (es decir, una tabla).
Por lo tanto, desde el punto de vista del usuario, una base de datos relacional contiene tablas
y nada más que tablas. En cada una de ellas hay una o más columnas y cero o más filas. En
cada posición de fila y columna de una tabla hay siempre exactamente un valor de datos.
Trabajo con la base de datos muestra del libro

La base de datos de muestra que se usa en este libro representa una compañía con departa-
mentos y empleados. Cada uno de éstos pertenece sólo a un departamento, el cual tiene uno
o más empleados. Los trabajos que realizan se centran en proyectos: cada empleado trabaja al
mismo tiempo en uno o más proyectos y cada proyecto, cuenta con la participación de uno o
más empleados.
Los datos de la base de datos de muestra se pueden representar utilizando cuatro tablas:
departamento
empleado
proyecto
trabaja_en
Las tablas 1-1 a 1-4 muestran todas las tablas de la base de datos de muestra.
La tabla departamento representa todos los departamentos de la compañía. Cada uno de
ellos tiene los siguientes atributos:
departamento (num_depto, nombre_depto, lugar)

num_depto representa el número único de cada departamento. nombre_depto es el nombre

y lugar es la ubicación del departamento correspondiente.
La tabla empleado representa todos los empleados que trabajan para una compañía. Cada
uno tiene los siguientes atributos:
empleado (num_emp, nombre_emp, apellido_emp, num_depto)
num_emp representa el número único de cada empleado. nombre_emp y apellido_emp

son el nombre y el apellido de cada empleado, respectivamente. Por último, num_depto es el
número del departamento al cual pertenece el empleado.
num_depto nombre_depto lugar

d1 Investigación Ciudad de México
d2 Contabilidad Santiago
d3 Marketing Ciudad de México
Tabla 1-1 Tabla departamento
num_emp nom_emp ape_emp num_depto

25348 Manuel Soriano d3
10102 Ana Jiménez d3
18316 Juan Bárcenas d1
29346 Jaime Junco d2
9031 Elsa Bertoni d2
2581 Elena Hernández d2
28559 Susana Morales d1
Tabla 1-2 Tabla empleado
num_proyecto nombre_proyecto presupuesto

p1 Apolo 120 000
p2 Géminis 95 000
p3 Mercurio 186 500
Tabla 1-3 Tabla proyecto
num_emp num_proyecto puesto fecha_ingreso

10102 p1 Analista 2006.10.1
10102 p3 Gerente 2008.1.1
25348 p2 Oficinista 2007.2.15

18316 p2 NULL 2007.6.1
29346 p2 NULL 2006.12.15
2581 p3 Analista 2007.10.15
9031 p1 Gerente 2007.4.15
28559 p1 NULL 2007.8.1
28559 p2 Oficinista 2008.2.1
9031 p3 Oficinista 2006.11.15
29346 p1 Oficinista 2007.1.4
Tabla 1-4 Tabla trabaja_en
Cada proyecto de una compañía se representa en la tabla proyecto, la cual tiene las
siguientes columnas:
proyecto (num_proyecto, nombre_proyecto, presupuesto)
num_proyecto representa el número único de cada proyecto. nombre_proyecto y

presupuesto especifican el nombre y el presupuesto de cada proyecto, respectivamente.
La tabla trabaja_en, que especifica la relación entre empleados y proyectos, tiene las
siguientes columnas:
trabaja_en (num_emp, num_proyecto, puesto, fecha_ingreso)
num_emp especifica el número de empleado y num_proyecto señala el número del proyecto

en el cual trabaja. La combinación de valores de datos que pertenecen a estas dos columnas
es siempre única. puesto y fecha_ingreso especifican la tarea y la fecha de inicio de un em-
pleado en el proyecto correspondiente, respectivamente.
Mediante el empleo de la base de datos de muestra es posible describir algunas
propiedades generales de los sistemas de bases de datos relacionales:
Las filas de una tabla no tienen un orden determinado.

Las columnas de una tabla tampoco lo tienen.
Toda columna debe tener un nombre único en una tabla. Por otra parte, las columnas
de tablas diferentes pueden tener el mismo nombre. (Por ejemplo, la base de datos de
muestra tiene una columna num_depto en la tabla departamento y una columna con
el mismo nombre en la tabla empleado.)
Todo elemento de datos individual de la tabla debe tener un valor único. Esto significa
que en toda posición de fila y columna de una tabla nunca hay un conjunto de múlti-
ples valores de datos.
En toda tabla hay al menos una columna (es decir, una combinación de columnas) con
la propiedad de que no tienen dos filas con la misma combinación de valores de datos).
En el modelo de datos relacionales, este identificador se conoce como clave candidata.
Si hay más de una clave candidata en una tabla, el diseñador de la base designa una de
ellas como la clave primaria de la tabla. Por ejemplo, la columna num_depto es la clave
primaria de la tabla departamento; las columnas num_emp y num_proyecto son las
claves primarias de las tablas empleado y proyecto, respectivamente. Por último, la
clave primaria de la tabla trabaja_en es la combinación de las columnas num_emp y
num_proyecto.
En una tabla nunca hay dos filas idénticas. (Esta propiedad sólo es teórica: el motor de
base de datos y todos los otros sistemas de bases de datos relacionales suelen permitir la
existencia de filas idénticas en una misma tabla.)
SQL: un lenguaje de bases de datos relacionales

El lenguaje de bases de datos relacionales SQL Server se denomina Transact-SQL. Es un
dialecto del lenguaje de bases de datos más importante de hoy día: Structured Query Lan-
guage (SQL). El origen de SQL está conectado muy de cerca con el proyecto llamado Sys-
tem R, que fue diseñado e implementado por IBM a principios de la década de los ochenta.
Este proyecto demostró que era posible, utilizando los fundamentos teóricos del trabajo de
E. F. Codd, construir un sistema de bases de datos relacionales.
En contraste con lenguajes tradicionales como C, C++ y Java, SQL es un lenguaje
orientado a objetos. (Los primeros se conocen también como lenguajes orientados a
registros.) Esto significa que SQL puede consultar muchas filas de una o más tablas
utilizando tan sólo una instrucción. Esta característica es una de las ventajas más importantes
de SQL, ya que permite el uso de este lenguaje en un nivel lógicamente más elevado que
aquel en el cual se pueden utilizar los lenguajes tradicionales.
Otra propiedad importante de SQL es su ausencia de procedimientos. Todo programa
escrito en un lenguaje procesal, o basado en procedimientos (C, C++, Java) describe cómo se
realiza una tarea, paso por paso. En contraste con este enfoque, SQL, como cualquier otro
lenguaje no procesal, describe qué es lo que el usuario desea. De esta forma, el sistema es
responsable de buscar la forma apropiada de satisfacer las peticiones de los usuarios.
SQL contiene dos sublenguajes: uno de definición de datos (DDL) y otro de
manipulación de datos (DML). Las instrucciones DDL se utilizan para describir los
esquemas de tablas de una base de datos. El lenguaje DDL contiene tres instrucciones SQL
genéricas: los objetos CREATE, ALTER y DROP. Estas instrucciones crean, alteran y
eliminan objetos de bases de datos, como bases de datos, tablas, columnas e índices. (Estas
instrucciones se analizan con detalle en el capítulo 5.)
En contraste con DDL, el lenguaje DML abarca todas las operaciones que manipulan
los datos. Siempre existen cuatro operaciones genéricas para manipular la base de datos:
recuperación, inserción, eliminación y modificación. La instrucción de recuperación
SELECT se describe en el capítulo 6, mientras que las instrucciones INSERT, DELETE y
UPDATE se describen con detalle en el capítulo 7.
Diseño de bases de datos

Diseñar una base de datos es una fase muy importante del ciclo de vida de una base de datos,
que precede a todas las otras fases, menos las de recopilación de requisitos y el análisis. Si el
diseño se crea meramente de forma intuitiva sin ningún plan, es muy probable que el pro-
ducto resultante no satisfaga los requisitos del usuario concernientes al desempeño. Otra
consecuencia de un mal diseño de la base de datos es la redundancia de datos superfluos, lo
cual tiene dos desventajas: la existencia de anomalías en los datos y el uso de una cantidad
innecesaria de espacio en el disco.
La normalización de los datos es un proceso durante el cual se prueban las tablas existentes
de una base para buscar ciertas dependencias entre las columnas de una tabla. Si existen tales
dependencias, la tabla se reestructura en múltiples (en general dos) tablas, lo cual elimina
cualquier tipo de dependencia. Si una de estas tablas generadas aún contiene dependencias
de datos, se debe repetir el proceso de normalización hasta que se eliminen todas ellas.
El proceso de eliminar la redundancia de datos que afecta una tabla se basa en la teoría
de las dependencias funcionales. Una dependencia funcional significa que mediante el uso
del valor conocido de una columna, el valor correspondiente de otra columna se puede
determinar siempre de forma única. (El mismo criterio se aplica a los grupos de columnas.)
Las dependencias funcionales entre las columnas A y B se denota por A B, lo que
especifica que un valor de la columna A siempre se puede usar para determinar el valor
correspondiente de la columna B. (“B depende funcionalmente de A.”)
El ejemplo que sigue muestra la dependencia funcional entre dos atributos de la tabla
empleado en la base de datos de muestra.
EJEMPLO 1.1
num_emp apellido_emp
Con el valor único del número de empleado, se puede determinar el apellido que le
corresponde (y todos los otros atributos). (Este tipo de dependencia funcional, donde una
columna depende de la clave primaria de una tabla, se conoce como dependencia funcional
trivial.)
Otro tipo de dependencia funcional se conoce como dependencia de valores múltiples. En
contraste con la dependencia funcional que se acaba de describir, la dependencia de valores
múltiples se especifica para atributos con valores múltiples. Esto significa que mediante el
empleo del valor conocido de un atributo (columna) se puede determinar de forma única el
correspondiente conjunto de valores de otro atributo de valores múltiples. La dependencia de
valores múltiples se denota con .
El ejemplo que sigue muestra la dependencia de valores múltiples que ocurre con dos
atributos del objeto LIBRO.
EJEMPLO 1.2
ISBN Autores
El ISBN de un libro determina siempre todos sus autores. Por lo tanto, el atributo
Autores es dependiente con valores múltiples del atributo ISBN.
Formas normales
Las formas normales se utilizan para el proceso de normalización de datos y, por lo tanto, pa-
ra el diseño de la base de datos. En teoría, existen al menos cinco formas normales diferentes,
de las cuales las tres primeras son las más importantes debido a su uso práctico. La tercera
forma normal de una tabla se puede obtener probando la primera y segunda formas normales
en los estados intermedios, y como tal, la meta del buen diseño de una base de datos se puede
lograr si todas las tablas que existen en ella están en la tercera forma normal.
NOTA
La dependencia de valores múltiples se utiliza para probar la cuarta forma normal de una tabla. Por lo tanto, este tipo
de dependencia no se usará más en este libro.
Primera forma normal

Primera forma normal (1NF) significa que una tabla no tiene atributos con valores múlti-
ples o atributos compuestos. (Un atributo compuesto contiene otros atributos, por lo cual se
puede dividir en partes más pequeñas.) Por definición, todas las bases de datos relacionales
están estructuradas en 1NF, ya que el valor de cualquier columna de una fila debe ser atómico
(es decir, tener un solo valor).
La tabla 1-5 demuestra 1NF mediante el empleo de parte de la tabla trabaja_en de la
base de datos de muestra. Las filas de la tabla trabaja_en se podrían agrupar utilizando el
número de empleado. La tabla 1-6 resultante no está en 1NF porque la columna num_
proyecto contiene un conjunto de valores (p1, p3).
Segunda forma normal

Una tabla está en la segunda forma normal (2NF) si está en 1NF y no hay una columna sin
clave dependiente de una clave primaria parcial de esa tabla. Esto significa que si (A,B) es
una combinación de dos columnas de la tabla que conforman la clave, no hay una columna
de la tabla que dependa sólo de A o sólo de B.
num_emp num_proyecto ...............

10102 p1 ...........
10102 p3 ...........
........... ........... .............
Tabla 1-5 Parte de la tabla trabaja_en
num_emp num_proyecto ...............

10102 (p1, p3) ...........
........... ........... .............
Tabla 1-6 Esta “tabla” no está en 1NF
Por ejemplo, la tabla 1-7 muestra la tabla trabaja_en1, que es idéntica a la tabla trabaja_
en salvo que tiene la columna adicional, num_depto. La clave primaria de esta tabla es la
combinación de las columnas num_emp y num_proyecto. La columna num_depto depende
de la clave parcial num_emp (y es independiente de num_proyecto), de modo que esta tabla
no está en 2NF. (La tabla original, trabaja_en, está en 2NF.)
NOTA
Toda tabla con una clave primaria de una columna está siempre en 2NF.
Tercera forma normal

Una tabla está en la tercera forma normal (3NF) si está en 2NF y no existen dependencias
funcionales entre columnas sin claves. Por ejemplo, la tabla empleado1 (vea la tabla 1-8), que
es idéntica a la tabla empleado salvo por la columna adicional, nombre_depto, no está en
3NF, ya que para cada valor conocido de la columna num_depto, el valor correspondiente
de la columna nombre_depto se puede determinar de manera única. (La tabla original,
empleado, así como todas las otras tablas de la base de datos de muestra, están en 3NF.)
num_emp num_proyecto puesto fecha_ingreso num_depto

10102 p1 Analista 2006.10.1 d3
10102 p3 Gerente 2008.1.1 d3
25348 p2 Oficinista 2007.2.15 d3
18316 p2 NULL 2007.6.1 d1
........ ........ ........ ............
Tabla 1-7 Tabla trabaja_en
num_emp nom_emp ape_emp num_depto nombre_depto

25348 Manuel Soriano d3 Mercadotecnia
10102 Ana Jiménez d3 Mercadotecnia
18316 Juan Bárcenas d1 Investigación
29346 Jaime Junco d2 Contabilidad
.......... .......... .......... .......... ..........
Tabla 1-8 Tabla empleado1
Modelo de relaciones de entidades

Los datos alojados en una base de datos se podrían diseñar con facilidad mediante el empleo
de sólo una tabla que contenga todos los datos. La desventaja principal de este diseño es su
alta redundancia de datos. Por ejemplo, si su base de datos contiene información relaciona-
da con empleados y sus proyectos (bajo el supuesto de que cada empleado trabaja al mismo
tiempo en uno o más proyectos y cada proyecto implica a uno o más empleados), los datos
almacenados en una tabla contienen muchas columnas y filas. La desventaja principal de esta
tabla es que resulta difícil conservar la coherencia de los datos debido a su redundancia.
El modelo de relaciones de entidades (ER) se utiliza para diseñar bases de datos relacionales
que eliminan la redundancia existente en los datos. El objeto básico del modelo ER es
una entidad (es decir, un objeto real). Cada entidad tiene varios atributos, los cuales son
propiedades de la entidad y por lo tanto la describen. Basándose en su tipo, un atributo
puede ser o tener:
Atómico (o de un solo valor) Un atributo atómico se representa siempre mediante

un valor único de una entidad en particular. Por ejemplo, el estado civil de una persona
es siempre un atributo atómico. La mayoría de los atributos son atómicos.
Valores múltiples Un atributo con valores múltiples puede tener uno o más valores
de una entidad en particular. Por ejemplo, Lugar como atributo de una entidad
llamada EMPRESA tiene múltiples valores, ya que cada empresa puede tener uno o
más lugares.
Compuesto Los atributos compuestos no son atómicos porque se ensamblan me-
diante algunos otros atributos atómicos. Un ejemplo típico de un atributo compuesto
es el domicilio de una persona, el cual se compone de atributos atómicos como Ciudad,
Código y Calle.
La entidad PERSONA del ejemplo 1.3 tiene varios atributos atómicos, un atributo
compuesto, Domicilio, y un atributo de valores múltiples, Título_universitario.
EJEMPLO 1.3
PERSONA (Num_personal, Nombre, Apellido, Domicilio(Ciudad,Código,Calle), #
{Título_universitario})
Cada entidad tiene uno o más atributos claves que son atributos (o una combinación de
dos o más atributos), cuyos valores son únicos de cada entidad en particular. En el ejemplo
1.3, el atributo Num_personal es el atributo clave de la entidad PERSONA.
Además de la entidad y el atributo, la relación es otro concepto básico del modelo ER.
Una relación existe cuando una entidad se refiere a otra (o más) entidades. El número de
entidades participantes define el grado de una relación. Por ejemplo, la relación trabaja_en
entre las entidades EMPLEADO y PROYECTO tiene un grado 2.
Toda relación existente entre dos entidades debe ser de uno de los tres tipos siguientes:
1:1, 1:N o M:N. (Esta propiedad de una relación también se conoce como relación
de cardinalidad.) Por ejemplo, la relación entre las entidades DEPARTAMENTO y
EMPLEADO es 1:N, ya que cada uno de éstos pertenece exactamente a un departamento,
el cual tiene uno o más empleados. Asimismo, la relación entre las entidades PROYECTO
y EMPLEADO es M:N, ya que cada proyecto cuenta con la participación de uno o más
empleados y cada uno de éstos trabaja al mismo tiempo en uno o más proyectos.
Una relación puede tener también sus propios atributos. La figura 1-1 muestra un ejemplo
de un diagrama ER. (El diagrama ER es la notación gráfica que se utiliza para describir el
modelo ER.)
num_proyecto nombre_proyecto Presupuesto

PROYECTO
num_depto nombre_depto Lugar
M
fecha_ingreso
DEPARTAMENTO trabaja_en
Puesto
1
N
N
trabaja_para EMPLEADO
num_empleado nombre apellido
Figura 1-1 Ejemplo de un diagrama ER
Con base en esta notación, las entidades se modelan mediante el uso de cajas rectangulares,
con el nombre de la entidad escrito dentro de la caja. Los atributos se muestran en óvalos y
cada atributo se adjunta a una entidad (o relación) en particular mediante una línea recta. Por
último, las relaciones se modelan con forma de diamantes y las entidades que participan en
la relación se adjuntan a ella por medio de líneas rectas. La relación de cardinalidad de cada
entidad se escribe en la línea correspondiente.
Convenciones de sintaxis
Este libro emplea las convenciones que se ilustran en la tabla 1-9 para la sintaxis de las ins-
trucciones Transact-SQL y para la indicación del texto.
NOTA
En contraste con los corchetes y los paréntesis angulares, que pertenecen a convenciones de sintaxis, los paréntesis, ( ),
pertenecen a la sintaxis de una instrucción y se deben teclear siempre.
Convención Indicación
Cursiva Nuevos términos o elementos destacados.
MAYÚSCULAS Palabras clave de Transact-SQL (por ejemplo, CREATE TABLE). Se puede obtener información adicional
acerca de las palabras clave del lenguaje Transact-SQL en el capítulo 5.
minúsculas Variables e instrucciones Transact-SQL (por ejemplo, CREATE TABLE nombre de tabla). (El usuario debe
reemplazar “nombre de tabla” con el nombre real de la tabla.)
var1|var2 Uso alternativo de los elementos var1 y var2. (Puede elegir sólo uno de los elementos separados por la
barra vertical.)
{ } Uso alternativo de más elementos.
Ejemplo: {expresión|USER|NULL}
[ ] Elemento o elementos opcionales.
Ejemplo: [FOR LOAD]
{ }... Elemento o elementos que se pueden repetir cualquier número de veces.
Ejemplo: {,@param1 typ1}...
negrita Nombre del objeto de base de datos (la base de datos misma, tablas, columnas) en el texto.
Predeterminado El valor predeterminado siempre va subrayado.
Ejemplo: ALL|DISTINCT
Tabla 1-9 Convenciones de sintaxis
Conclusión
Todos los sistemas de bases de datos ofrecen las siguientes características:

Integridad de datos
Seguridad de las bases de datos
El capítulo que sigue le muestra cómo instalar SQL Server 2008.
Ejercicios
E.1.1
¿Qué significa “independencia de datos” y cuáles dos formas de independencia de datos
existen?
E.1.2
¿Cuál es el concepto principal del modelo relacional?
E.1.3
¿Qué representa la tabla empleado en el mundo real? ¿Y qué representa la fila en esta tabla
con los datos de Ana Jiménez?
E.1.4
¿Qué representa la tabla trabaja_en en el mundo real (y en relación con las otras tablas de la
base de datos de muestra)?

Microsoft SQL Server 2008 Manual de Referencia

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Microsoft SQL Server 2008 Manual de Referencia

Cargado por

Copyright:

Formatos disponibles

Capítulo 1

Sistemas de base de datos

Sistemas de bases de datos:

Sistemas de bases de datos

Diseño de bases de datos

Sistemas de bases de datos: descripción

Programas de aplicación de bases de datos

Un programa de aplicación de base de datos es software de uso especial diseñado e

implementado por usuarios, o bien implementado por alguna compañía de software. En

Variedad de interfaces de usuario

Las siguientes secciones describen estas características brevemente.

Variedad de interfaces de usuario

Independencia de datos físicos

Independencia de datos lógicos

tiva, en el capítulo 5, e integridad procesal [o de procedimientos], en el capítulo 14.)

Copia de seguridad y recuperación

Seguridad de bases de datos

Sistemas de bases de datos relacionales

Trabajo con la base de datos muestra del libro

departamento (num_depto, nombre_depto, lugar)

num_depto representa el número único de cada departamento. nombre_depto es el nombre

empleado (num_emp, nombre_emp, apellido_emp, num_depto)

num_emp representa el número único de cada empleado. nombre_emp y apellido_emp

num_depto nombre_depto lugar

Tabla 1-1 Tabla departamento

num_emp nom_emp ape_emp num_depto

Tabla 1-2 Tabla empleado

num_proyecto nombre_proyecto presupuesto

Tabla 1-3 Tabla proyecto

num_emp num_proyecto puesto fecha_ingreso

25348 p2 Oficinista 2007.2.15

proyecto (num_proyecto, nombre_proyecto, presupuesto)

num_proyecto representa el número único de cada proyecto. nombre_proyecto y

trabaja_en (num_emp, num_proyecto, puesto, fecha_ingreso)

num_emp especifica el número de empleado y num_proyecto señala el número del proyecto

Las filas de una tabla no tienen un orden determinado.

SQL: un lenguaje de bases de datos relacionales

Diseño de bases de datos

Primera forma normal

Segunda forma normal

num_emp num_proyecto ...............

num_emp num_proyecto ...............

Tabla 1-6 Esta “tabla” no está en 1NF

Tercera forma normal

num_emp num_proyecto puesto fecha_ingreso num_depto

num_emp nom_emp ape_emp num_depto nombre_depto

Modelo de relaciones de entidades

Atómico (o de un solo valor) Un atributo atómico se representa siempre mediante

num_proyecto nombre_proyecto Presupuesto

num_empleado nombre apellido

Figura 1-1 Ejemplo de un diagrama ER

Variedad de interfaces de usuario

El capítulo que sigue le muestra cómo instalar SQL Server 2008.

También podría gustarte