Documente Academic
Documente Profesional
Documente Cultură
Entre persona.
Entre un objeto y persona(s).
Entre objetos.
El dato, al ser una representacin (que tendr que ser interpretada) contiene caractersticas de
objetividad. En el caso de ser personas las que interpreten un dato, existir la posibilidad de
subjetividad al momento de la interpretacin (conclusin de la informacin).
Informacin
Informacin: significado percibido al recibir un mensaje. La percepcin humana es, por naturaleza,
subjetiva. Por lo tanto la informacin referida a un mismo dato tendr la posibilidad de ser resultado
de varias interpretaciones.
Si se tienen varias persona que interpretaran un mismo dato o conjunto de datos, deber existir un
acuerdo para la forma de interpretarlos (obtener el significado o informacin). Para la obtencin de
informacin es necesario un proceso: El proceso mental de interpretacin o un proceso automatizado
que de forma y significado a los datos accedidos en algn medio. Otro aspecto importante es que
muchas veces el hecho de contar con ms datos o con datos colaterales al estrictamente requerido
permite un mejor proceso para la obtencin de informacin. Otra definicin: Informacin, es el grado
de disminucin de la incertidumbre sobre algo.
Base de Datos
Una base de datos es un conjunto de datos organizados de tal manera que pueda extraerse
informacin.
En esta definicin general no se hace mencin al medo donde residirn los datos ni la forma o
tecnologa de acceso a los mismos.
Muchas veces el solo hecho de cambiar de medio de almacenamiento (como en el ejemplo mostrado)
obliga a un mnimo de organizacin. La organizacin de los datos persigue el objetivo que estos
puedan ser compartidos por varios usuarios.
Sistema de Administracin de Base de Datos
DBMS por sus siglas en Ingles (DataBase Management System). Software que administra el acceso a
los datos, permitiendo su almacenamiento, consulta y actualizacin. Tiene la capacidad de responder
a mltiples usuarios accediendo en forma concurrente a los dato. Provee facilidades para la
administracin del conjunto como toma de respaldos y recuperacin.
El DBMS permite tener los datos de toda la organizacin (incluida la informacin de sus principales
entidades) de forma integrada, de manera que estos se encuentren disponibles a consultas o
actualizaciones de transacciones realizadas por el personal de la empresa, clientes de la misma, a
travs de aplicaciones de un sistema de informacin o directamente a travs de un lenguaje que sea
comprendido por el DBMS.
Este lenguaje, en el caso de bases de datos relacionales (RBDMS) es el SQL, que se vera mas
adelante. El lenguaje no solo debe de permitir la comunicacin para acceder los datos, sino par
definirlos. Actualmente los software RBDMS se encuentran en diversas plataformas, aunque son
desarrollados para arquitecturas tanto mainframe como cliente/servidor (tema tocado mas adelante)
corriendo en el back end (host o servidor) usando la infraestructura de red disponible para la
comunicacin con los usuarios.
Portabilidad
Caracterstica de permitir transportar de una manera transparente o fcil un producto de una
plataforma a otra. En el caso de los DBMS, no solo es la consideracin de portabilidad del producto
(el software mismo) sino los datos que la base de datos administra.
Universalidad
Se refiere a los mltiples tipos de datos que puede manejar un DBMS, los que actualmente se
denominan datos multimedia.
Disponibilidad (Permanente e ininterrumpida)
Actualmente es uno de los factores cruciales, pues el servicio de base de datos apoya a las
aplicaciones crticas de la operativa de los negocios.
Escalabilidad Horizontal
Capacidad de incrementar la cantidad de usuarios de la base de datos o la cantidad de estaciones
con conexin a base de datos. Una de las diferencias entre los gestores de base de datos para
microcomputadora y DBMS para servidores es precisamente la capacidad de los segundos para
escalar horizontalmente. Generalmente el costo de licencia de un DBMS est relacionado con la
cantidad de usuarios concurrentes. Es as que si bien un producto particular puede proveer esta
facilidad, existir un costo asociado.
Escalabilidad Vertical
Capacidad para incrementar el tamao y/o la potencia del servidor y as obtener mejoras con mismo
producto.
Tambin llamado nivel fsico, describe CMO son almacenados los datos en la base de
datos. Una parte de este nivel debe de ser visible el DBA y totalmente visible a quienes
desarrollan software del tipo DBMSs. En este nivel es importante el conocimiento (visibilidad)
del ambiente operativo donde correr el software BDMS.
Cliente/Servidor
Es la actual arquitectura para sistemas con bases de datos basada en la distribucin de
aplicaciones y/o datos en una red de computadoras, conocido por sus siglas C/S, tambin es
sinnimo de computacin abierta que permite utilizacin de hardware variado, sin
dependencia de un solo proveedor.
Tipos de Servidores
Servidor de Archivos
El cliente (tpicamente una PC) requiere archivos a travs de la red. Se requier mucho
intercambio de mensajes. De utilidad para repositorios de diferentes tipos de archivos
Request Brokers).
Servidor Web
Los clientes se comunican a travs de protocolo HTTP para que el servidor provea los
requerimientos correspondientes (un documento HTML por ejemplo).
Tipos de aplicaciones
Las aplicaciones cliente/servidor tambin pueden ser clasificadas (diferenciadas) de acuerdo
a
EL CLIENTE
En el cliente corre la parte de la aplicacin correspondiente. Lo hace en el sistema operativo,
que a su vez provee la interfaz usuario (U.I) hace ya buen tiempo grafica (GUI) u orientada a
objetos (OOUI) y puede acceder diferentes servicios distribuidos.
Para acceder a servicios distribuidos lo hace a travs del componente middleware, quien
maneja los servicios que no son locales. En el cliente tambin corre un componente del
middleware de administracin de sistemas distribuidos (DSM).
EL SERVIDOR
El componente de aplicacin en el servidor generalmente corre sobre un software para la
correspondiente plataforma (del servidor): un DBMS con SQL, un monitor de transacciones,
groupware, servidores de objetos y el web. Depende del S.O. para interfazar con el
componente middleware que hace los requerimientos de servicios. Tambin corre un
componente del DSM.
EL MIDDLEWARE
El componente middleware corre tanto en el cliente como el servidor. Se puede clasificar en
tres categoras de middleware:
1. El software (o mejor dicho los protocolos) de transporte
Provee comunicacin a travs de WANs y LANs y por supuesto la necesaria combinacin
LAN/WAN/LAN. Estos protocolos vienen como drivers en los sistemas operativos
modernos, los que proveen interfaces muy bien definidas entre componentes de manera
de llegar desde las aplicaciones hasta los adaptadores de red.
2. El sistema operativo de red
Aunque el trmino de red ya prcticamente quedo en el pasado, pues los sistemas
operativos ofrecen la funcionalidad son usadas en un ambiente cliente servidor tales
como servicios de directorio, comparticin de recursos, seguridad, etc. Facilidades para
internet/intranet son proporcionadas tambin por los sistemas operativos.
3. Servicios especficos
Tambin deben de correr en ambos lados, cliente y servidor, de manera de proveer la
funcionalidad necesaria como por ejemplo acceso y recuperacin de datos de una base
de datos, correo electrnico, brokers de objetos y otros.
Estas entidades se representan en un diagrama con unos rectngulos, como los siguientes.
Coche
ATRIBUTO
Empleado
Cargo del
Empleado
Los atributos definen o identifican las caractersticas de entidad (es el contenido de esta
entidad). Cada entidad contiene distintos atributos, que dan informacin sobre esta entidad.
Estos atributos pueden ser de distintos tipos (numricos, texto, fecha).
Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad Coches,
que nos darn informacin sobre los coches de nuestro supuesto taller.
Unos posibles atributos seran
propietario, marca, modelo y muchos otros que complementen la informacin de cada coche.
Los atributos se representan como crculos que descienden de una entidad, y no es necesario
representarlos todos, sino los ms significativos, como a continuacin.
RELACIN
Es un vnculo que nos permite definir una dependencia entre varias entidades, es decir, nos
permite exigir que varias entidades compartan ciertos atributos de forma indispensable.
Por ejemplo, los empleados del taller (de la entidad Empleados) tienen un cargo (segn la
entidad Cargo del empleado). Es decir, un atributo de la entidad Empleados especificar
que cargo tiene en el taller, y tiene que ser idntico al que ya existe en la entidad Cargo del
empleado.
Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades
mediante lneas.
RELACIONES DE CARDINALIDAD
Podemos encontrar distintos tipos de relaciones segn como participen en ellas las entidades.
Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo
pueden compartir varios empleados.
Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada
extremo de la relacin que especifica cuantos objetos o cosas (de cada entidad) pueden
intervenir en esa relacin.
Uno a uno: Una entidad se relaciona nicamente con otra y viceversa. Por ejemplo, si
tuvisemos una entidad con distintos chasis y otra con matrculas deberamos de determinar
que cada chasis solo puede tener una matrcula (y cada matrcula un chasis, ni ms en
ningn caso).
Uno a varios o varios a uno: determina que un registro de una entidad puede estar
relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha
sido en el caso anterior del trabajador del taller.
Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios
registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios
mecnicos distintos y esos mecnicos pueden reparar varios coches distintos.
Los indicadores numricos indican el primero el nmero mnimo de registros en una relacin y
posteriormente el mximo (si no hay lmite se representa con una n).
CLAVES
Es el atributo de una entidad, al que le aplicamos una restriccin que lo distingue de los
dems registros (no permitiendo que el atributo especfico se repita en la entidad) o le aplica
un vnculo (exactamente como comentbamos en las relaciones). Estos son los distintos
tipos:
Superclave: aplica una clave o restriccin a varios atributos de la entidad, para as asegurarse
que en su conjunto no se repitan varias veces y as no poder entrar en dudas al querer
identificar un registro.
Clave primaria: identifica inequvocamente un solo atributo no permitiendo que se repita en la
misma entidad. Como sera la matrcula o el nmero de chasis de un coche (no puede existir
dos veces el mismo).
Clave externa o clave fornea: este campo tiene que estar estrictamente relacionado con la
clave primaria de otra entidad, para as exigir que exista previamente ese clave.
Anteriormente
hemos hablado
de
ello
cuando
comentbamos que
un
empleado
EDAD
19
SEXO
Varn
Sally Boyce
23
Mujer
Tony Stark
18
Varn
Bill Ballucci
34
Varn
Tina Graver
19
Mujer
En la relacin Estudiante tiene tres atributos (NOMBRE, EDAD, SEXO) y cinco tuplas, cada una
representando nombre, edad y sexo de un estudiante. Por tanto el grado y la cardinalidad de
ESTUDIANTE son tres y cinco, respectivamente: las definiciones matemticas de las relaciones se
desarrolla empezando por la nocin de dominios. Un dominio es una coleccin de valores. Dados
varios atributos, A1, A2,, An, con subdominios D1, D2, , Dn un caso de relacin de grado n es
simplemente un sub conjunto del producto cartesiano D1 x D2 Dn. Esta definicin destaca una
importante propiedad de las relaciones, a saber, que son conjuntos de tuplas en el sentido
matemtico: una relacin en ningn momento puede tener
mayora de los sistemas relacionales no imponen una restriccin, ya que en diversas situaciones
pueden ocurrir duplicados y puede ser til mantenerlos.
Claves Primarias y Forneas (externas)
Llave Principal:
Llave Fornea: Columna(s) que contiene(n) los valores de un dominio que sirven al mismo
As, la nica diferencia entre nuestro uso de identificadores y claves es que en el modelo
relacional solo se acepta la identificacin interna.
NORMALIZACIN
INTRODUCCIN
Una vez creada el diseo de la base de datos, debemos analizarla para asegurarnos de que carece
de problemas potenciales. Para ello, seguiremos un proceso llamado normalizacin, en el que
identificamos la existencia de problemas potenciales como duplicacin y redundancia de datos, e
implantaremos maneras de corregir esos problemas.
El objetivo de la normalizacin es convertir las relaciones no normalizadas (tablas que satisfacen la
definicin de una relacin pero que pueden contener grupos repetidos) en varios tipos de formas
normalizadas. Una tabla de una forma normalizada en concreto posee un determinado y deseable
conjunto de propiedades. Aunque hay varias formas normalizadas, las ms comunes son la primera
forma normalizada, la segunda forma normalizada y la tercera forma normalizada. La normalizacin
es un proceso en el que una tabla que est en primera forma normalizada, es mejor que una tabla
que no est en primera forma normalizada, una tabla en segunda forma normalizada es mejor que
otra que est en primera forma normalizada, y as sucesivamente. El objetivo de este proceso es
permitirnos obtener una tabla o conjunto de tablas y producir un nuevo conjunto de tablas que
representa la misma informacin pero que carece de problemas.
tPedido
codiPedi
fechaPedi
codiArti
cantiArti
21608
10/20/201
AT94
11
0
10/20/201
DR93
21613
0
10/21/201
DW11
KL62
1
4
21614
0
10/21/201
KT03
0
10/23/201
BV06
21619
0
10/23/201
CD52
DR93
4
1
21623
0
10/23/201
KV29
21610
21617
0
Figura 2.7. Datos de pedido no normalizado.
Para convertir la tabla en primera forma normalizada, eliminamos el grupo repetido de esta manera:
tPedido (codiPedi, fechaPedi, codiArti, cantiArti)
En la figura 2.8 vemos la tabla en primera forma normalizada. En la figura 2.7, la segunda fila indica
que el artculo DR93 y el artculo DW11 estn incluidos en el pedido 21610. En la figura 2.8 esta
informacin est representada por dos filas, la segunda y la tercera. La clave principal en la tabla
tPedido no normalizada era la columna codiPedi solamente. La clave principal de la tabla normalizada
es ahora la combinacin de las columnas codiPedi y codiArti.
Cuando convertimos una tabla no normalizada en una tabla en primera forma normalizada, la clave
principal de la tabla en primera forma normalizada es normalmente la clave principal de la tabla no
normalizada concatenada con la clave del grupo repetido, que es la columna del grupo repetido que
diferencia una aparicin del grupo repetido de otra dentro de una fila determinada de la tabla. En la
tabla tPedido, codiArti era la clave del grupo repetido y codiPedi la clave principal de la tabla. Al
convertir los datos no normalizados en primera forma normalizada, la clave principal es ahora la
concatenacin de las columnas codiPedi y codiArti.
tPedido
codiPedi
fechaPedi
codiArti
cantiArti
21608
10/20/201
AT94
11
21610
0
10/20/201
DR93
21610
0
10/20/201
DW11
21613
0
10/21/201
KL62
21614
0
10/21/201
KT03
21617
0
10/23/201
BV06
21617
0
10/23/201
CD52
21619
0
10/23/201
DR93
21623
0
10/23/201
KV29
0
Figura 2.8. Datos del pedido convertidos en primera forma normalizada.
fechaPedi
codiArti
descripArti
cantiArti
precioCoArti
21608
21610
21610
21613
21614
21617
21617
10/20/2010
10/20/2010
10/20/2010
10/21/2010
10/21/2010
10/23/2010
10/23/2010
AT94
DR93
DW11
KL62
KT03
BV06
CD52
Iron
Gas Range
Washer
Dryer
Dishwasher
Home Gym
Microwave
11
1
1
4
2
2
4
$21.95
$495.00
$399.99
$329.95
$595.00
$12.95
$150.00
21619
21623
Oven
10/23/2010 DR93
Gas Range
1
10/23/2010 KV29
Treadmill
2
Figura 2.9. Ejemplo de tabla tPedido.
$495.00
$325.99
1. Actualizaciones: Si tenemos que cambiar la descripcin del artculo DR93, tenemos que
hacerlo dos veces: una vez en cada una de las filas en que aparece el artculo DR93.
Actualizar la descripcin del artculo ms de una vez hace que el proceso de actualizacin
sea mucho ms pesado y lleve ms tiempo.
2. Datos inconsistentes: No hay nada en el diseo que impida que el artculo DR93 tenga dos
descripciones diferentes en la base de datos. De hecho, si el artculo DR93 aparece en 20
filas de la tabla, este artculo puede llegar a tener 20 descripciones diferentes en la base de
datos.
3. Adiciones: Cuando intentamos aadir un artculo nuevo y su descripcin a la base de datos,
nos encontramos con un grave problema. Como la clave principal de la tabla tPedido consiste
tanto en codiPedi como en codiArti, necesitamos valores para ambas columnas para aadir
una fila nueva a la tabla. Si aadimos un artculo a la tabla que an no tenga ningn pedido,
Qu ponemos como codiPedi? La nica solucin es crear un codiPedi ficticio y despus
sustituirlo por el codiPedi real una vez se reciba realmente un pedido para este artculo. Esto
no es una solucin aceptable.
4. Eliminaciones: Si eliminamos el pedido 21608 de la base de datos y es el nico pedido que
contiene el artculo AT94, al eliminar el pedido tambin se elimina toda la informacin sobre el
artculo AT94. Por ejemplo, ya no podramos saber que el artculo AT94 es una plancha.
Estos problemas aparecen porque tenemos una columna, descripArti, dependiente de solo una parte
de la clave principal, codiArti, y no de toda la clave principal. Esta situacin lleva a la definicin de la
segunda forma normalizada. La segunda forma normalizada representa una mejora sobre la primera
forma normalizada porque elimina las anomalas de actualizacin en estas situaciones. Una tabla
(relacin) est en segunda forma normalizada (2NF) cuando est en primera forma normalizada y no
hay ninguna columna no-clave (es decir, una columna que no sea parte de la clave principal) que
dependa de slo una parte de la clave principal.
Nota: Cuando la clave principal de una tabla contiene una sola columna, la tabla est
automticamente en segunda forma normalizada.
Podemos identificar el problema fundamental con la tabla tPedido: no est en segunda forma
normalizada. Aunque es importante identificar el problema, lo que necesitamos realmente es un
mtodo para corregirlo, tenemos que poder convertir tablas en segunda forma normalizada. En primer
lugar, tome el subconjunto del conjunto de columnas que conforman la clave principal y comience una
nueva tabla con este subconjunto como su clave principal. Para la tabla tPedido, el nuevo diseo es:
(codiPedi,
(codiArti,
(codiPedi, codiArti,
En segundo lugar, site cada una de las otras columnas con la clave principal adecuada, es decir,
site cada una con el mnimo conjunto de columnas de que depende. Para la tabla tPedido, aada las
nuevas columnas de esta manera:
(codiPedi, fechaPedi)
(codiArti, descripArti)
(codiPedi, codiArti, cantiArti, precioCoArti)
A cada una de estas nuevas tablas se le asigna un nombre descriptivo basado en el significado y
contenido de la tabla, como tPedido, tArticulo y tDetallePedido. En la figura 2.10 vemos ejemplos de
estas tablas.
En la figura 2.10, al convertir la tabla original tPedido en una tabla tPedido, una tabla tArticulo y una
tabla tDetallePedido elimina las anomalas de actualizacin. Slo aparece una descripcin una vez
para cada artculo, por tanto no tenemos la redundancia que exista en el diseo original de la tabla.
Al cambiar la descripcin del artculo DR93 de Gas Range a por ejemplo, Deluxe Range, ahora es un
proceso muy sencillo que implica un solo cambio. Como la descripcin de un artculo aparece en un
solo lugar, no es posible tener varias descripciones para un solo artculo en la base de datos al mismo
tiempo. Para aadir un nuevo artculo y su descripcin, creamos una nueva fila en la tabla tArticulo,
independientemente de si ese artculo tiene pedidos pendientes o actuales o no. Adems, al borrar el
pedido 21680 no se borra el cdigo de artculo AT94 de la base de datos porque sigue existiendo en
la tabla tArticulo. Por ltimo, no hemos perdido ninguna informacin al convertir la tabla tPedido en
segunda forma normalizada. Podemos reconstruir los datos en la tabla original a partir de los datos de
las nuevas tablas.
tPedido
codiPedi
fechaPedi
codiArti
descripArti
cantiArti
precioCoArti
21608
21610
21610
21613
21614
21617
21617
10/20/2010
10/20/2010
10/20/2010
10/21/2010
10/21/2010
10/23/2010
10/23/2010
AT94
DR93
DW11
KL62
KT03
BV06
CD52
Iron
Gas Range
Washer
Dryer
Dishwasher
Home Gym
Microwave
11
1
1
4
2
2
4
$21.95
$495.00
$399.99
$329.95
$595.00
$12.95
$150.00
21619
21623
10/23/2010 DR93
10/23/2010 KV29
Oven
Gas Range
Treadmill
1
2
$495.00
$325.99
nombreClien
direcClien
Clie
ciudad
balan
limiCre
codi
ape
nombre
Clien
Clien
Clien
Fillmore
$6550.00
$7500.00
20
$10000.00 35
$7500.00 65
n
148
Als
282
356
Sport
Brookings Direct
Fergusons
Greenway
3827 Devon
382
Grove
Northfiel
$431.50
$5785.00
408
462
524
Wildwood
1828 Raven
3829 Central
838
d
Crystal
Grove
Fillmore
$5285.25 $5000.00 35
$3412.00 $10000.00 65
$12762.00 $15000.00 20
Hull
Richard
Perez Juan
Kaiser Valerie
608
Johnsons
Ridgeland
372 Oxford
Sheldon
$2106.00
$10000.00 65
Perez
Juan
687
Department Store
Lees
Sport
and 282
Altonville
$2851.00
$5000.00
35
Hull
Richard
725
Appliance
Deerfields
Sheldon
$248.00
$7500.00
35
Hull
Richard
842
Seasons
All Season
Columbia
28 Lakeview Grove
$8221.00 $7500.00
Figura 2.11. Ejemplo de la tabla tCliente
20
Kaiser Valerie
Appliance
and 2837
Evergreen
Four 282
Kaiser Valerie
Hull
Perez
Richard
Juan
candidata. Se ha formado una nueva tabla, que consiste en codiVende como clave principal y las
columnas apeVende y nombreVende, de esta manera: tCliente (codiClien, nombreClien, balanClien,
limiCreClien, codiVende) y
tVendedor (codiVende, apeVende, nombreVende)
En la figura 2.12 vemos la tabla original tCliente y las tablas creadas al convertir la tabla original a
tercera forma normalizada.
Ha corregido este nuevo diseo de la tabla tCliente todos los problemas previamente identificados?
El nombre del vendedor aparece solo una vez, con lo que se evita la redundancia y se simplifica el
proceso de cambiar el nombre de un vendedor. En este diseo no se permite que un vendedor tenga
nombre diferentes en una base de datos.
Para aadir un nuevo vendedor a la base de datos; aadiremos una fila a la tabla tVendedor, no es
necesario que un nuevo vendedor represente a algn cliente. Por ltimo, eliminar a todos los clientes
de un vendedor determinado no eliminar el registro del vendedor de la tabla tVendedor, sino que su
nombre se mantendr en la base de datos. Podemos reconstruir todos los datos en la tabla original a
partir de los datos del nuevo conjunto de tablas. Todos los problemas mencionados anteriormente ya
se han resuelto.
tCliente
codi
nombreClien
direcClien
Clien
ciudad
balan
limiCre
codi
ape
nombre
Clien
Clien
Clien
Vend
Vend
Vende
e
Kaise
Valerie
Richar
Fillmore
$6550.00
$7500.00
e
20
Greenway
3827 Devon
Grove
$431.50
$10000.0
35
r
Hull
Fergusons
382
Northfiel
$5785.00
0
$7500.00
65
d
Perez Juan
408
Wildwood
1828 Raven
d
Crystal
$5285.25
$5000.00
35
Hull
462
Bargains Galore
3829
Grove
$3412.00
$10000.0
65
d
Perez Juan
524
Klines
Central
838
Fillmore
$12762.0
0
$15000.0
20
Kaise
608
Ridgeland
Johnsons Department 372 Oxford
Sheldon
0
$2106.00
0
$10000.0
65
r
Perez Juan
687
Store
Lees
Altonville $2851.00
0
$5000.00
35
Hull
Richar
725
Appliance
Deerfields
Sheldon
$7500.00
35
Hull
d
Richar
842
Seasons
All Season
Kaise
d
Valerie
148
Als
Appliance
282
Sport
Brookings Direct
356
Sport
and 2837
and 282
Evergreen
Four 282
Columbia
28 Lakeview Grove
$248.00
$8221.00
$7500.00
20
r
codiVende apeVende nombreVende
20
Kaiser
Valerie
Richar
Valerie
35
65
Hull
Richard
Perez
Juan
Figura 2.12. La tabla tCliente convertida en tercera forma normalizada.
Preguntas y Respuestas
Pregunta: Convierta la siguiente tabla en tercera forma normalizada. En esta tabla, codiAlum
determina a nombreAlum, numeCredi, codiTutor y nombreTutor. codiTutor determina a nombreTutor.
codiCurso determina a descripCurso.
Paso 1: Elimine el grupo repetido para convertir la tabla en primera forma normalizada de esta
manera:
tAlumno
(codiAlum,
nombreAlum,
numeCredi,
codiTutor,
nombreTutor,
La tabla tAlumno est ahora en primera forma normalizada porque no tiene grupos repetidos. Sin
embargo no est en segunda forma normalizada porque nombreAlum depende solo de codiAlum, que
es solo una parte de la clave principal.
Paso 2: Convierta la tabla tAlumno en segunda forma normalizada. En primer lugar, para cada parte
de la clave principal, empiece una tabla con esa parte como una clave dejando lo siguiente:
(codiAlum,
(codiCurso,
(codiAlum, codiCurso,
Despus, site el resto de columnas con el conjunto de columnas ms pequeo de las que dependen,
as:
tAlumno
(codiAlum,
nombreAlum,
numeCredi,
codiTutor,
nombreTutor)
tCurso
(codiCurso,
descripCurso)
tAlumnoCurso (codiAlum, codiCurso, notaCurso)
Ahora estas tablas estn en segunda forma normalizada, y las tablas tCurso y tAlumnoCurso tambin
estn en tercera forma normalizada. Sin embargo, la tabla tAlumno no est en tercera forma
normalizada, porque contiene un determinante (codiTutor) que no es una clave candidata.
Paso 3: Convierta la tabla tAlumno en tercera forma normalizada eliminando la columna que depende
del determinante codiTutor y situndola en una tabla aparte, de esta manera:
(codiAlum, nombreAlum, numeCredi, codiTutor)
(codiTutor, nombreTutor)
SQL Server
SQL server es un sistema administrador para Bases de Datos relacionales basadas en la arquitectura
Cliente/Servidor (RDBMS) que usa Transact SQL para mandar peticiones un cliente y el SQL Server.
SQL Server usa la arquitectura Cliente/Servidor para separar la carga de trabajo en tareas que corran
en computadoras tipo Servidor y tareas que corran en computadoras tipo Cliente:
relacin.
Lenguaje interactivo de manipulacin de datos: El LMD de SQL incluye lenguajes de
una transaccin.
SQL incorporado y dinmico: Esto quiere decir que se pueden incorporar instrucciones de
SQL en lenguajes de programacin como: C++, C, Java, PHP, Cobol, Pascal y Fortran.
Autorizacin: El LDD incluye comandos para especificar los derechos de acceso a las
relaciones y a las vistas.
Tipos de Datos
Algunos de los tipos de datos bsicos de SQL son:
Date: una fecha de calendario que contiene el ao (de cuatro cifras), el mes y el da.
Time: La hora del da en horas minutos segundos (el valor predeterminado es 0).
Optimizacin
Como ya se dijo antes, y suele ser comn en los lenguajes de acceso a bases de datos de alto nivel,
el SQL es un lenguaje declarativo. O sea, que especifica qu es lo que se quiere y no cmo
conseguirlo, por lo que una sentencia no establece explcitamente un orden de ejecucin.
El orden de ejecucin interno de una sentencia puede afectar seriamente a la eficiencia del SGBD,
por lo que se hace necesario que ste lleve a cabo una optimizacin antes de su ejecucin. Muchas
veces, el uso de ndices acelera una instruccin de consulta, pero ralentiza la actualizacin de los
datos. Dependiendo del uso de la aplicacin, se priorizar el acceso indexado o una rpida
actualizacin de la informacin. La optimizacin difiere sensiblemente en cada motor de base de
datos y depende de muchos factores.
Existe una ampliacin de SQL conocida como FSQL (Fuzzy SQL, SQL difuso) que permite el acceso
a bases de datos difusas, usando la lgica difusa. Este lenguaje ha sido implementado a nivel
experimental y est evolucionando rpidamente.
Lenguaje de definicin de datos (DDL)
El lenguaje de definicin de datos (en ingls Data Definition Language, o DDL), es el que se encarga
de la modificacin de la estructura de los objetos de la base de datos. Incluye rdenes para modificar,
borrar o definir las tablas en las que se almacenan los datos de la base de datos. Existen cuatro
operaciones bsicas: CREATE, ALTER, DROP y TRUNCATE.
CREATE | CREAR
Este comando permite crear objetos de datos, como nuevas bases de datos, tablas, vistas
y procedimientos almacenados.
Ejemplo (crear una tabla)
CREATE TABLE 'CUSTOMERS';
ALTER | MODIFICAR
Este
comando
permite
modificar
la
estructura
de
una
tabla
objeto.
Se
pueden
agregar/quitar campos a una tabla, modificar el tipo de un campo, agregar/quitar ndices a una tabla,
modificar un trigger, etc.
Ejemplo (agregar columna a una tabla)
ALTER TABLE 'ALUMNOS' ADD EDAD INT UNSIGNED;
DROP | ELIMINAR
Este comando elimina un objeto de la base de datos. Puede ser una tabla, vista, ndice, trigger,
funcin, procedimiento o cualquier objeto que el motor de la base de datos soporte. Se puede
combinar con la sentencia ALTER.
Ejemplo
DROP TABLE 'ALUMNOS';.
TRUNCATE | BORRAR TABLA
Este comando trunca todo el contenido de una tabla. La ventaja sobre el comando DROP, es que si
se quiere borrar todo el contenido de la tabla, es mucho ms rpido, especialmente si la tabla es muy
grande. La desventaja es que TRUNCATE slo sirve cuando se quiere eliminar absolutamente todos
los registros, ya que no se permite la clusula WHERE. Si bien, en un principio, esta sentencia
parecera ser DML (Lenguaje de Manipulacin de Datos), es en realidad una DDL, ya que
internamente, el comando TRUNCATE borra la tabla y la vuelve a crear y no ejecuta ninguna
transaccin.
Ejemplo
TRUNCATE TABLE 'NOMBRE_TABLA';
Palabra clave que indica que la sentencia de SQL que queremos ejecutar es de seleccin.
Indica que queremos seleccionar todos los valores.Es el valor por defecto y no suele
WHERE
GROUP
BY
HAVING
funciones agregadas.
Especifica una condicin que debe cumplirse para que los datos sean devueltos por la
ORDER
BY
Ejemplo:
Para formular una consulta a la tabla Coches y recuperar los campos matricula, marca, modelo, color,
numero_kilometros, num_plazas debemos ejecutar la siguiente consulta. Los datos sern devueltos
ordenados por marca y por modelo en orden ascendente, de menor a mayor. La palabra
clave FROM indica que los datos sern recuperados de la tabla Coches .
bien la matrcula FK-938-ZL . Se puede utilizar la clusula WHERE solamente, en combinacin con
tantas condiciones como queramos.
Una Condicin WHERE puede ser negada a travs del Operador Lgico NOT. La Siguiente consulta
devolver todos los datos de la tabla Coches, menos el que tenga la Matrcula MF-234-ZD .
La Siguiente consulta utiliza la condicional DISTINCT, la cual nos devolver todos los valores distintos
formados por los Campos Marca y Modelo. De la tabla coches.
numero_kilometros,
num_plazas
FROM coches
ORDER BY marca ASC,modelo DESC; Este ejemplo, selecciona todos los campos matricula, marca,
modelo, color, numero_kilometros y num_plazas de la tabla coches, ordenndolos por los campos
marca y modelo, marca en forma ascendente y modelo en forma descendente.
SELECT matricula,
marca,
modelo,
color,
numero_kilometros, num_plazas
FROM
coches
ORDER BY 2;
Este ejemplo, selecciona todos los campos matrcula, marca, modelo, color, numero_kilometros y
num_plazas de la tabla coches, ordenndolos por el campo marca, ya que aparece en segundo lugar
dentro de la lista de campos que componen la SELECT.
INSERT | INSERTAR
Una sentencia INSERT de SQL agrega uno o ms registros a una (y slo una) tabla en una base de
datos relacional.
Forma bsica
el
valor
por
omisin.
Los
valores
especificados
(o
implcitos)
por
la
sentencia INSERT debern satisfacer todas las restricciones aplicables. Si ocurre un error de sintaxis
o si alguna de las restricciones es violada, no se agrega la fila y se devuelve un error.
Ejemplo
(asumiendo
que
'nombre'
'nmero'
'agenda_telefonica'):
son
las
nicas
columnas
de
la
tabla
Una caracterstica de SQL (desde SQL-92) es el uso de constructores de filas para insertar mltiples
filas a la vez, con una sola sentencia SQL:
UPDATE My_table SET field1 = 'updated value asd' WHERE field2 = 'N';
DELETE
Una sentencia DELETE de SQL borra uno o ms registros existentes en una tabla.
Forma bsica
Autentificacin Windows
Cuando se usa el usuario no necesita de una cuenta SQL Server, para conectarse. Un
administrador del sistema debe definir ya sean cuentas de Windows o grupos de Windows
como cuentas validas de SQL Server.
Administrador del Sistema (sa) es una cuenta especial. De forma predeterminada, esta
asignada a la funcin fija de servidor sysadmin y no es posible cambiarla. Se incluye por
compatibilidad con versiones anteriores de Microsoft SQL Server. Aunque sa es una cuenta
de administrador integrada, no debe de utilizarse habitualmente. En su lugar, los
administradores deben de pertenecer a la funcin fija de servidor sysadmin y conectarse con
sus propios nombres de inicio de sesin. Solo debe de usarse sa cuando no haya otro modo
de iniciar sesin en SQL Server; por ejemplo, cuando los dems administradores del sistema
no estn disponibles o cuando hayan olvidado sus contraseas.
ROLES Y FUNCIONES
SQL Server proporciona roles de nivel de servidor para ayudarle a administrar los permisos de un
servidor. Estos roles son entidades de seguridad que agrupan otras entidades de seguridad. Los roles
de nivel de servidor se aplican a todo el servidor en lo que respecta a su mbito de
permisos. (Los roles son como los grupos del sistema operativo Windows.)
Los roles fijos de servidor se proporcionan por comodidad y compatibilidad con versiones
anteriores. Siempre que sea posible, asigne permisos ms especficos.
SQL Server proporciona nueve roles fijos de servidor. Los permisos que se conceden a los roles fijos
de servidor no se pueden modificar. A partir de SQL Server 2012, puede crear roles de servidor
definidos por el usuario y agregarles permisos de nivel de servidor.
Puede agregar entidades de seguridad a nivel de servidor (inicios de sesin de SQL Server, cuentas
de Windows y grupos de Windows) a los roles de nivel de servidor. Cada miembro de un rol fijo de
servidor puede agregar otros inicios de sesin a ese mismo rol. Los miembros de roles de servidor
definidos por el usuario no pueden agregar otras entidades de seguridad de servidor al rol.
ROLES FIJOS DE NIVEL DE SERVIDOR
En la tabla siguiente se muestran los roles fijos de nivel de servidor y sus capacidades.
Rol
de
fijo
Descripcin
nivel
de
servidor
sysadmi
Los miembros del rol fijo de servidor sysadmin pueden realizar cualquier actividad en
n
serverad
el servidor.
Los miembros del rol fijo de servidor serveradmin pueden cambiar las opciones de
min
securitya
dmin
sus
propiedades. Administran
los
permisos
de
servidor
GRANT,
DENY
La capacidad de conceder acceso a Motor de base de datos y configurar los permisos de usuario perm
la mayora de los permisos de servidor. El rol securityadmin se debe tratar como equivalente al rol
processa
Los miembros del rol fijo de servidor processadmin pueden finalizar los procesos que
dmin
setupad
min
bulkadmi
n
diskadmi
INSERT.
El rol fijo de servidor diskadmin se usa para administrar archivos de disco.
n
dbcreato
Los miembros del rol fijo de servidor dbcreator pueden crear, modificar, quitar y
r
public
public se implementa de manera diferente que otros roles. Sin embargo, se pueden conceder, denegar
(Transact-
Tipo
Descripcin
Metadatos
Devuelve una lista de roles de nivel de servidor.
SQL)
sp_helpsrvrolemember
Metadatos
(Transact-SQL)
sp_srvrolepermission
Metadatos
(Transact-SQL)
IS_SRVROLEMEMBER
Metadatos
(Transact-SQL)
sys.server_role_members
Metadatos
(Transact-SQL)
sp_addsrvrolemember
Comando
nivel de servidor.
Agrega un inicio de sesin como miembro de un rol
(Transact-SQL)
de
sp_dropsrvrolemember
Comando
(Transact-SQL)
nivel
de
CREATE
SERVER
(Transact-SQL)
ALTER
SERVER
SERVER
(Transact-SQL)
IS_SRVROLEMEMBER
SERVER
ROLE
Comando
ROLE en su lugar.
Crea un rol de servidor definido por el usuario.
ROLE
Comando
(Transact-SQL)
DROP
ALTER
Comando
el usuario.
Quita un rol de servidor definido por el usuario.
Funcin
(Transact-SQL)
Consideraciones adicionales
Si usted est moviendo un proyecto que se encuentra en fases de automatizacin (ambiente de
desarrollo), hacia un servidor diferente (pero igual de desarrollo) y desea conservar las instancias de
Proceso (casos), tenga en cuenta que los adjuntos de estos casos no estarn dentro de la
informacin del backup.
Por lo tanto en el hipottico escenario en el que desee trasladar los casos de un ambiente de
desarrollo, deber considerar mover tambin la ubicacin de stos (sea el Servidor BPM, un Servidor
diferente de archivos, o un ECM).
Crear un Backup
Para crear un backup de su Base de datos:
Autentquese en su instancia de SQL Server (login) a travs de SQL Server Management Studio.
Ubique la Base de datos y d clic derecho sobre sta. Seleccione la opcin Backup... desde las
tareas:
Ntese que debe seleccionar una ruta vlidar para almacenar el archivo resultante (.bak).
Si no desea utilizar la ruta por defecto, puede navegar y seleccionar otro directorio. Si utiliza otro
directorio, asegrese de contar con los permisos de escritura sobre l.
Importante
Ntese que podr crear 2 tipos bsicos de Backups:
Full Backup: Esta opcin crea un backup completo (de toda la Base de datos). Con esta opcin se
limpian las transacciones almacenadas en el log de transacciones.
Differential Backup: Es un backup diferencial, donde se almacena la parte que ha cambiado con
respecto al ltimo backup completo (Full Backup). El log de transacciones tambin es truncado.
Para restaurar un proyecto de Bizagi a su ltimo estado por medio de un backup, se recomienda crear
y utilizar los backups en modo Full backup.
Por ejemplo, los backups automticos que toma Bizagi los realiza de esta manera.
ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
Si queremos que los parmetros de un procedimiento almacenado sean de entrada-salida debemos
especificarlo a travs de la palabra clave OUTPUT, tanto en la definicin del procedure como en la
ejecucin.
El siguiente ejemplo muestra la definicin de un procedure con parmetros de salida.
AS
BEGIN
IF (SELECT SALDO FROM CUENTAS
WHERE NUMCUENTA = @numCuenta) < 0
BEGIN
RETURN 1
END
ELSE
RETURN 0
END
El siguiente ejemplo muestra como ejecutar el procedure y obtener el valor devuelto.
FROM MOVIMIENTOS
INNER JOIN CUENTAS ON MOVIMIENTOS.IDCUENTA = CUENTAS.IDCUENTA
WHERE NUMCUENTA = @numCuenta
ORDER BY FXMOVIMIENTO DESC
END
La ejecucin del procedimiento se realiza normalmente.
20070000000150.99100.9950.0020070825
16:18:36.490
2007000000010.9950.9950.0020070823
16:20:41.183
20070000000150.990.9950.0020070823
16:16:29.840
2007000000010.9950.9950.0020070823
16:14:05.900
TRIGGERS
Un trigger( o desencadenador) es una clase especial de procedimiento almacenado que se ejecuta
automticamente cuando se produce un evento en el servidor de bases de datos.
SQL Server proporciona los siguientes tipos de triggers:
Trigger DML, se ejecutan cuando un usuario intenta modificar datos mediante un evento de
lenguaje de manipulacin de datos (DML). Los eventos DML son instrucciones INSERT,
2005
crea
administra
automticamente
ambas
tablas.
La
estructura
de
las
tablas inserted y deleted es la misma que tiene la tabla que ha desencadenado la ejecucin del
trigger.
La primera tabla (inserted) solo est disponible en las operaciones INSERT y UPDATE y en ella estn
los
valores
resultantes
despues
de
la
insercin o
actualizacin.
Es
decir,
los
datos
a la
ejecucin
de
la
actualizacin
borrado.
Es
decir,
los
datos
que
BEGIN
-- SET NOCOUNT ON impide que se generen mensajes de texto
-- con cada instruccin
SET NOCOUNT ON;
INSERT INTO HCO_SALDOS
(IDCUENTA, SALDO, FXSALDO)
SELECT IDCUENTA, SALDO, getdate()
FROM INSERTED
END
La siguiente instruccin provocar que el trigger se ejecute:
UPDATE CUENTAS
SET SALDO = SALDO + 10
WHERE IDCUENTA = 1
Una consideracin a tener en cuenta es que el trigger se ejecutar aunque la instruccion DML
(UPDATE,
INSERT
DELETE
no
haya
afectado
ninguna
fila.
En
este
ROLLBACK
END
En este caso obtendremos el siguiente mensaje de error:
La transaccin termin en el desencadenador. Se anul el lote.
Podemos activar y desactivar Triggers a travs de las siguientes instrucciones.
Trigger DDL
Los trigger DDL se ejecutan en respuesta a una variedad de eventos de lenguaje de definicin de
datos (DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP
de Transact-SQL, y a determinados procedimientos almacenados del sistema que ejecutan
operaciones de tipo DDL.
La sintaxis general de un trigger es la siguiente.
CREATE TRIGGER <trigger_name, sysname, table_alter_drop_safety>
ON DATABASE
FOR <data_definition_statements, , DROP_TABLE, ALTER_TABLE>
AS
BEGIN
...
END
La siguiente instruccin impide que se ejecuten sentencias DROP TABLE y ALTER TABLE en la base
de datos.