Caso de Estudio

Caso de Estudio: Campeonato de Ajedrez 2
Índice:
Introducción. . . . . . . . . .3
Objetivo General. . . . . . . . .4
Objetivos específicos.. . . . . . .11, 12
Planteamiento del Problema. . . . . . .5
Justificación. . . . . . . . . .6
Marco Teórico. . . . . . . . .7
8 de octubre del 2010

Diseño Conceptual
Diagrama Entidad Relación. . . . . .11
Diagrama Relaciona. . . . . . .12
Diccionario de Datos . . . . . . .18
Bibliografía. . . . . . . . . .20
Introducción:
El lenguaje de consulta estructurado o SQL,(Structured Query Lenguage) El lenguaje de
consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el
motor de base de datos.
Lenguaje de definición de datos (DDL): El lenguaje de definición de datos (en

inglés Data Definition Language, o DDL), es el que se encarga de la modificación de la
estructura de los objetos de la base de datos. Existen cuatro operaciones básicas: CREATE,
ALTER, DROP y TRUNCATE.
Lenguaje de manipulación de datos (DML): Un lenguaje de manipulación de

datos (Data Manipulation Language, o DML en inglés) es un lenguaje proporcionado por el
sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de
consulta o manipulación de los datos, organizados por el modelo de datos adecuado.
Lenguaje de Consulta de Dato (LQD): DQL es la abreviatura del Data Query Language
(lenguaje de consulta de datos) de SQL. El único comando que pertenece a este lenguaje es el
versátil comando SELECT
Nuestro proyecto o Caos de Estudio se llama “Campeonato de Ajedrez” en el cual

aprenderemos básicamente en que consiste el crear una Base de Datos en donde se
muestren todas las características generales y datos personales guardados de cada uno de
los datos de los participantes y sus exclusivas, países, partidas, hoteles, jornadas, salas y
movimientos, utilizando los siguientes métodos dentro del diseño conceptual los cuales los
podrás encontrar a lo largo de este proyecto, como lo son:
*Entidades
*Atributos
*Diagrama Entidad Relación
*Diagrama Relacional
*Normalización
*Diccionario de Datos
Objetivo General
El principal objetivo es que al crear la base de datos para un torneo llamado “Campeonato
de Ajedrez” para que esta tenga un mejor control de participantes y que no exista
redundancia de datos y que el usuario realice diversas consultas sin ninguna dificultad.
Llevando a cabo los conocimientos del alumno sobre los conceptos básicos antes
mencionados el alumno diseñara una Base de Datos para cumplir con las expectativas del
cliente. El alumno creara Diagramas Relacionales y Diagramad Entidad Relación para que
con estos verifique o distinga sus entidades y atributos. El objetivo que conlleva este
proyecto es que el alumno practique el manejo del lenguaje SQL, y tome practica para la
creación de diferentes base de datos, que sepa identificar lo que son; entidades, atributos
que diseñe los diagramas Relacionales y Entidad Relación así mismo que identifique las
llaves primarias y foráneas.
Planteamiento del Problema:
CAMPEONATO DE AJEDREZ
El club de Ajedrez de Villatortas de Arriba, ha sido encargado por la Federación

Internacional de Ajedrez de la organización de los próximos campeonatos mundiales que se
celebrarán en la mencionada localidad. Por este motivo, desea llevar a una base de datos
toda la gestión relativa a participantes, alojamientos y partidas teniendo en cuenta que: En

el campeonato participan jugadores y árbitros. De ambos se requiere conocer el número de
asociado, nombre, dirección, teléfono de contacto y campeonatos en los que ha participado
(como jugador o como árbitro). De los jugadores se precisa además el nivel de juego en una
escala de 1 a 10. Ningún árbitro puede participar como jugador.
Los países envían al campeonato un conjunto de jugadores y árbitros, aunque no todos los
países envían participantes. Todo jugador y árbitro es enviado por un único país. Un país
puede ser representado por otro país. Cada país se identifica por un número correlativo
según su orden alfabético e interesa conocer además de su nombre, el número de clubes de
ajedrez existentes en el mismo.

Cada partida se identifica por un número correlativo (Cod_P), la juegan dos jugadores y la
arbitra un árbitro. Interesa registrar las partidas que juega cada jugador y el color (blancas o
negras) con el que juega. Ha de tenerse en cuenta que un árbitro no puede arbitrar a
jugadores enviados por el mismo país que le ha enviado a él. Todo participante participa en
al menos una partida.
Tanto jugadores como árbitros se alojan en uno de los hoteles en los que se desarrollan las
partidas, se desea conocer en qué hotel y en qué fechas se ha alojado cada uno de los
participantes. Los participantes pueden no permanecer en Villatortas durante todo el
campeonato, sino acudir cuando tienen que jugar alguna partida alojándose en el mismo o
distinto hotel. De cada hotel, se desea conocer el nombre, la dirección y el número de
teléfono.
El campeonato se desarrolla a lo largo de una serie de jornadas (año, mes, día) y cada
partida tiene lugar en una de las jornadas aunque no tengan lugar partidas todas las
jornadas.
Cada partida se celebra en una de las salas de las que pueden disponer los hoteles. Se desea
conocer el número de entradas vendidas en la sala para cada partida. De cada sala, se desea
conocer la capacidad y medios de que dispone (radio, televisión, vídeo, …) para facilitar la
retransmisión de los encuentros. Una sala puede disponer de varios medios distintos. De
cada partida se pretende registrar todos los movimientos que la componen. La
identificación de movimiento se establece en base a un número de orden dentro de cada
partida. Para cada movimiento se guarda la jugada (5 posiciones) y un breve comentario
realizado por un experto.
Justificación:
En este caso de estudios, se creara una BD para el “Campeonato de Ajedrez”, además de

satisfacer las necesidades del cliente con respecto a su Base de Datos, se le diseñara lo que
es un diagrama relacional para visualizar los campos y así poder crear el diagrama entidad
relación, esto se realizara con el lenguaje de consultas SQL, este es un lenguaje declarativo
de acceso a bases de datos relacionales que permite especificar diversos tipos de
operaciones en éstas.
El cliente requiere de una BD para llevar un control del club de ajedrez; ya sea por sus
participantes (árbitros y jugadores), los hoteles, las partidas, y una serie de características
que vienen detallados en el caso de estudio.
Marco Teórico
El lenguaje de consulta estructurado o SQL,(Structured Query Lenguage) El lenguaje de
consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el
motor de base de datos.
Lenguaje de definición de datos (DDL): El lenguaje de definición de datos (en

inglés Data Definition Language, o DDL), es el que se encarga de la modificación de la
estructura de los objetos de la base de datos. Existen cuatro operaciones básicas: CREATE,
ALTER, DROP y TRUNCATE.
Lenguaje de manipulación de datos (DML): Un lenguaje de manipulación de

datos (Data Manipulation Language, o DML en inglés) es un lenguaje proporcionado por el
sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de
consulta o manipulación de los datos, organizados por el modelo de datos adecuado.
Lenguaje de Consulta de Dato (LQD): DQL es la abreviatura del Data Query

Language (lenguaje de consulta de datos) de SQL. El único comando que pertenece a este
lenguaje es el versátil comando SELECT Este comando permite:

♦ Obtener datos de ciertas columnas de una tabla (proyección)
♦ Obtener registros (filas) de una tabla de acuerdo con ciertos criterios (selección)
♦ Mezclar datos de tablas diferentes (asociación, join)
♦ Realizar cálculos sobre los datos
♦Agrupar datos
Definiciones Básicas:
Entidades: Se puede definir cono entidad a cualquier objeto, real o abstracto, que existe en
un contexto determinado o puede llegar a existir y del cual deseamos guardar información.
". Las entidades las podemos clasificar en:
A. Regulares: aquellas que existen por sí mismas y que la existencia de un ejemplar en la

entidad no depende de la existencia de otros ejemplares en otra entidad.
B. Débiles: son aquellas entidades en las que se hace necesaria la existencia de

ejemplares de otras entidades distintas para que puedan existir ejemplares en esta
entidad.
Atributos: Las entidades se componen de atributos que son cada una de las propiedades o
características que tienen las entidades.
Existen cuatro tipos de atributos: Obligatorio Opcional
A. Obligatorios: aquellos que deben

tomar un valor y no se permite ningún
Multievaluado
ejemplar no tenga un valor
determinado en el atributo.
B. Opcional: aquellos atributos que

Monoevaluad
pueden tener valores o no o
tenerlo.
C. Monoevaluado: aquel atributo que sólo puede tener un único valor.
D. Multievaluado: aquellos atributos que pueden tener varios valores.
La representación gráfica de los atributos, en función del tipo es la siguiente:
Existen atributos, llamados derivados, cuyo valor se obtiene a partir de los valores de otros
atributos.
Los atributos son las columnas de una relación y describen características particulares de
ella.

Tuplas: Cada uno de los renglones en una relación conteniendo valores para cada uno de
los atributos.
Dominios: Se debe considerar que cada atributo (columna) debe ser atómico, es decir, que
no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de
datos.
Diagrama Entidad –Relación
Generalmente todo modelo tiene una

representación gráfica, para el caso de datos el
modelo más popular es el modelo entidad-
relación o diagrama E/R.
Se denomina así debido a que precisamente

permite representar relaciones entre entidades
(objetivo del modelado de datos).
El modelo debe estar compuesto por:
• Entidades
• Atributos
• Relaciones
• Cardinalidad
• Llaves
 Entidades: todo lo que existe y es capaz de
ser descrito (sustantivo).
 Atributos: es una característica (adjetivo)
de una entidad que puede hacer 1 de tres
cosas:
• Identificar
• Relacionar
• Describir
Llaves
• Super llave: conjunto de uno o más atributos que "juntos" identifican de manera
única a una entidad
• Llave candidata: es una super llave mínima
•Llave primaria: la seleccionada para identificar a los elementos de un conjunto de
entidades.
Diagrama Relacional

Puede resultar confuso el concepto de modelo entidad-relación vs modelo relacional, quizás
porque ambos comparten casi las mismas palabras. Como se mencionó en la sección
anterior, el objetivo del modelo relacional es crear un "esquema" (schema), lo cual como se
mencionará posteriormente consiste de un conjunto de "tablas" que representan
"relaciones", relaciones entre los datos.
Estas tablas, pueden ser construídas de diversas maneras:
• Creando un conjunto de tablas iniciales y aplicar operaciones de normalización

hasta conseguir el esquema más óptimo. Las técnicas de nomalización se explican
más adelante en este capítulo.
• Convertir el diagrama e-r a tablas y posteriormente aplicar también operaciones de

normalización hasta conseguir el esquema óptimo.
La primer técnica fue de las primeras en existir y, como es de suponerse, la segunda al

ser más reciente es mucho más conveniente en varios aspectos:
• El partir de un diagrama visual es muy útil para apreciar los detalles, de ahí que se
llame modelo conceptual.
• El crear las tablas iniciales es mucho más simple a través de las reglas de
conversión.
• Se podría pensar que es lo mismo porque finalmente hay que "normalizar" las tablas
de todas formas, pero la ventaja de partir del modelo e-r es que la "normalización"
es mínima por lo general.
• Lo anterior tiene otra ventaja, aún cuando se normalice de manera deficiente, se

garantiza un esquema aceptable, en la primer técnica no es así.
Normalización: Una base de datos tiene que ser diseñada antes de que pueda ser creada y
usada. El diseño debe ajustarse a estándares que permitan ahorro de memoria, acceso
rápido, fácil mantenimiento, portabilidad, facilidad de futuros mejoramientos, buen

desempeño y eficiencia de costos, entre otros. El diseño lógico final de una base de datos
debe ser tal que equilibre un desempeño óptimo junto con la integridad de la información.
Esto puede ser logrado a través de un proceso conocido como Normalización. La base de
datos debe estar en un estado de "Forma completamente normalizada".
Normalización es una serie de reglas que involucra análisis y transformación de las

estructuras de los datos en relaciones que exhiban propiedades únicas de consistencia,
mínima redundancia y máxima estabilidad.
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las
relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:
 Evitar la redundancia de los datos.

 Evitar problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla
sea considerada como una relación tiene que cumplir con algunas restricciones:
 Cada columna debe tener su nombre único.

 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.
Diseño Conceptual
Diagrama Relacional
Objetivos Específico:
*El alumno por medio del diagrama relacional aprenderá a distinguir los símbolos que este
lleva como lo que son entidades, atributos. Especificara las llaves primarias y las llaves
foráneas.
Diagrama Entidad Relación
Objetivos Específico:
*El alumno realizara una representación grafica (Diagrama Entidad Relación) para el caso
de estudios. En este representara las relaciones entre entidades usando las llaves primarias o
foráneas según sea el caso.
---------------------------------------Creación de la base de Datos---------------------------------
CREATE DATABASE Campeonato_Ajedrez ON

PRIMARY
(
NAME=Campeonato_Ajedrez_Data2,
FILENAME='D:\Archivos de programa\Microsoft SQL
Server\Campeonato_Ajedrez_Data2.MDF',
SIZE=50MB,
MAXSIZE=100MB,
FILEGROWTH=10%
)
LOG ON
(
NAME=Campeonato_Ajedrez_Log2,
FILENAME='D:\Archivos de programa\Microsoft SQL
Server\Campeonato_Ajedrez_Log2.LDF',
SIZE=15MB,
MAXSIZE=40MB,
FILEGROWTH=10%
)

--------------------Creacion de tablas-----------------------
--Tabla participantes--
CREATE TABLE dbo.Participantes (
ID_Asociado int IDENTITY (1, 1) NOT NULL ,
Nombre nvarchar (20) NOT NULL ,
Direccion nvarchar (24) NOT NULL ,
Telfono nvarchar (10) NULL ,
Campeonato nvarchar (10)null
) ON [PRIMARY]
GO
-----------------------------------------------
Subtabla jugadores--
CREATE TABLE dbo.Jugadores (
ID_Asociado int NOT NULL ,
Nivel nvarchar (10)NOT NULL ,
) ON [PRIMARY]
GO
--Subtabla arbitros--
CREATE TABLE dbo.Arbitros (
ID_Asociado int NOT NULL ,
) ON [PRIMARY]
GO
------------------------------------------------
Tabla hoteles--
CREATE TABLE dbo.Hoteles (
Direccion nvarchar (24) NOT NULL ,
Telfono nvarchar (10) NULL ,
) ON [PRIMARY]
GO
--Tabla de la relacion alojan--

CREATE TABLE dbo.Alojan (
Fecha_de_entrada datetime NOT NULL ,
Fecha_de_salida datetime NOT NULL ,
Nombre_Hotel nvarchar (20)NOT NULL ,
ID_Asociado int IDENTITY (1, 1) NOT NULL ,
) ON [PRIMARY]
GO

--Tabla paises--
CREATE TABLE dbo.Paises (
ID_Pais int IDENTITY (1, 1) NOT NULL ,
Num_Clubes int NOT NULL ,
Participante int NOT NULL ,
) ON [PRIMARY]
GO
--Tabla salas--
CREATE TABLE dbo.Salas (
Codigo_sala int IDENTITY (1, 1) NOT NULL ,
Capacidad nvarchar (20) NOT NULL ,
Medios nvarchar(20) null,
Nombre_Hotel nvarchar(20)not null
) ON [PRIMARY]
GO
--Tabla Partidas--
CREATE TABLE dbo.Partidas (
Codigo_partida int IDENTITY (1, 1) NOT NULL ,
Jornada nvarchar (20) NOT NULL ,
Sala int not null,
Arbitro int not null,
) ON [PRIMARY]
GO
--Tabla relacion celebran--

CREATE TABLE dbo.celebran (
Entradas nvarchar (20) NOT NULL ,

Partida int not null,
sala int not null
) ON [PRIMARY]
GO
--Tabla movimientos--
CREATE TABLE dbo.Movimientos (
Jugada nvarchar (20) NULL ,
Movimiento nvarchar (25) NULL,
Comentario nvarchar (50) NULL,

Partida int NOT NULL
) ON [PRIMARY]
GO
--Tabla relacion juegan--

CREATE TABLE dbo.Juegan (
Color nvarchar (20) NULL ,
Jugador int NOT NULL,
Partidas int NOT NULL
) ON [PRIMARY]
GO
-------------------------Llaves Primarias--------------------
id_paises--
ALTER TABLE dbo.Paises
ADD CONSTRAINT PK_ID_Pais PRIMARY KEY NONCLUSTERED (ID_Pais)
--id_asociado--
ALTER TABLE dbo.Participantes
ADD CONSTRAINT PK_ID_Asociado PRIMARY KEY NONCLUSTERED
(ID_Asociado)
--nombre(hotel)--
ALTER TABLE dbo.Hoteles
ADD CONSTRAINT PK_Nombre PRIMARY KEY NONCLUSTERED (Nombre)
--codigo_sala--
ALTER TABLE dbo.Salas
ADD CONSTRAINT PK_Codigo_sala PRIMARY KEY NONCLUSTERED

(Codigo_sala)
--codigo_partida--
ALTER TABLE dbo.Partidas
ADD CONSTRAINT PK_Codigo_Partida PRIMARY KEY NONCLUSTERED
(Codigo_Partida)
--id_asociado--
ALTER TABLE dbo.Jugadores
ADD CONSTRAINT PK_ID_Asociado_AA PRIMARY KEY NONCLUSTERED

(ID_Asociado)
--id_asociado2--
ALTER TABLE dbo.Arbitros
ADD CONSTRAINT PK_ID_Asociado_AAA PRIMARY KEY NONCLUSTERED
(ID_Asociado)
--------------------------Llaves Foraneas--------------------
--Alojan(Nombre_hotel, ID_Asociado)--
ALTER TABLE dbo.Alojan WITH NOCHECK
ADD CONSTRAINT FK_Nombre
FOREIGN KEY(Nombre_Hotel) REFERENCES dbo.Hoteles(Nombre)
ALTER TABLE dbo.Alojan WITH NOCHECK

ADD CONSTRAINT FK_ID_Asociado
FOREIGN KEY(ID_Asociado) REFERENCES
dbo.Participantes(ID_Asociado)
GO
--Arbitros(ID_Asociado)--
ALTER TABLE dbo.Arbitros WITH NOCHECK
ADD CONSTRAINT FK_ID_AsociadoA
--Celebran(Partida,sala)--
ALTER TABLE dbo.celebran WITH NOCHECK
ADD CONSTRAINT FK_Partida
FOREIGN KEY(Partida) REFERENCES dbo.Partidas(Codigo_partida)
ALTER TABLE dbo.celebran WITH NOCHECK

ADD CONSTRAINT FK_sala
FOREIGN KEY(sala) REFERENCES dbo.Salas(Codigo_sala)
--Juegan(Jugador,Partidas)--
ALTER TABLE dbo.Juegan WITH NOCHECK
ADD CONSTRAINT FK_Jugador
FOREIGN KEY(Jugador) REFERENCES dbo.Jugadores(ID_Asociado)

ADD CONSTRAINT FK_Partidas

FOREIGN KEY(Partidas) REFERENCES dbo.Partidas(Codigo_partida)
--Jugadores(ID_asociado)--
ALTER TABLE dbo.Jugadores WITH NOCHECK
ADD CONSTRAINT FK_asociado

ADD CONSTRAINT FK_Jugador2
FOREIGN KEY(Jugador) REFERENCES dbo.Jugadores(ID_Asociado)
-------------------ALTER TABLE dbo.Juegan DROP CONSTRAINT
FK_Jugador2
--Movimientos(Partida)--
ALTER TABLE dbo.Movimientos WITH NOCHECK
ADD CONSTRAINT FK_partidaA
FOREIGN KEY(Partida) REFERENCES dbo.Partidas(Codigo_partida)
--Paises(Participante)--
ALTER TABLE dbo.Paises WITH NOCHECK
ADD CONSTRAINT FK_participante
FOREIGN KEY(Participante) REFERENCES
--Partidas(Sala,Arbitro)--
ALTER TABLE dbo.Partidas WITH NOCHECK
ADD CONSTRAINT FK_SalaA
FOREIGN KEY(Sala) REFERENCES dbo.Salas(Codigo_sala)
ALTER TABLE dbo.Partidas WITH NOCHECK

ADD CONSTRAINT FK_partidaAA
FOREIGN KEY(Arbitro) REFERENCES dbo.Arbitros(ID_Asociado)
--Salas(nombre_hotel)--
ALTER TABLE dbo.Salas WITH NOCHECK
ADD CONSTRAINT FK_nom_hotel
FOREIGN KEY(Nombre_Hotel) REFERENCES dbo.Hoteles(Nombre)
Diccionario de Datos
PARTICIPANTES
Propiedades Campo Tipo de Datos Longitud
PK ID_Asociado Int Identity
NN Nombre Nvarchar 20
NN Dirección Nvarchar 24
Teléfono Nvarchar 10
Campeonato Nvarchar 10
JUGADORES
NN Nivel Nvarchar 10
ARBITROS
HOTELES
PK Nombre Nvarchar 20
NN Direccion Nvarchar 24
Telefono Nvarchar 10

ALOJAN
NN Fecha_de_entrada Datetime
NN Fecha_de_salida Datetime
FK Nombre_Hotel Nvarchar 20
FK ID_Asociado int Identity
PAISES
PK ID_Pais Int Identity
NN Nombre Nvarchar 20
NN Num_Clubes Int
FK Participante Int
SALAS
PK Codigo_sala Int Identity
NN Capacidad Nvarchar 20
Medios Nvarchar 20
FK Nombre_Hotel Nvarchar 20
PARTIDAS
PK Codigo_partida Int Identity
NN Jornada Nvarchar 20
FK Sala Int
FK Arbitro Int
CELEBRAN
NN Entradas Nvarchar 20
FK Partida Int
FK Sala Int
MOVIMIENTOS
Jugada Nvarchar 20
Movimiento Nvarchar 25
Comentario Nvarchar 50
FK Partida Int
JUEGAN
Color Nvarchar 20

FK Jugador Int
FK Partidas Int
Bibliografía:
Ing. Yeni Garduño
Microsoft SQL Server
Sistemas Computacionales Avanzados McGrawHill
http://www.scribd.com/doc/2892930/Unidad-4-Lenguaje-SQL-II-Consultas

Caso de Estudio

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

Caso de Estudio

Cargado por

Copyright:

Formatos disponibles

Caso de Estudio: Campeonato de Ajedrez 2

Objetivos específicos.. . . . . . .11, 12

Planteamiento del Problema. . . . . . .5

8 de octubre del 2010

Diagrama Entidad Relación. . . . . .11

Diagrama Relaciona. . . . . . .12

Diccionario de Datos . . . . . . .18

Lenguaje de definición de datos (DDL): El lenguaje de definición de datos (en

Lenguaje de manipulación de datos (DML): Un lenguaje de manipulación de

8 de octubre del 2010

Nuestro proyecto o Caos de Estudio se llama “Campeonato de Ajedrez” en el cual

8 de octubre del 2010

Planteamiento del Problema:

El club de Ajedrez de Villatortas de Arriba, ha sido encargado por la Federación

toda la gestión relativa a participantes, alojamientos y partidas teniendo en cuenta que: En

8 de octubre del 2010

En este caso de estudios, se creara una BD para el “Campeonato de Ajedrez”, además de

8 de octubre del 2010

Lenguaje de definición de datos (DDL): El lenguaje de definición de datos (en

Lenguaje de manipulación de datos (DML): Un lenguaje de manipulación de

Lenguaje de Consulta de Dato (LQD): DQL es la abreviatura del Data Query

8 de octubre del 2010

A. Regulares: aquellas que existen por sí mismas y que la existencia de un ejemplar en la

B. Débiles: son aquellas entidades en las que se hace necesaria la existencia de

Existen cuatro tipos de atributos: Obligatorio Opcional

A. Obligatorios: aquellos que deben

B. Opcional: aquellos atributos que

C. Monoevaluado: aquel atributo que sólo puede tener un único valor.

D. Multievaluado: aquellos atributos que pueden tener varios valores.

La representación gráfica de los atributos, en función del tipo es la siguiente:

8 de octubre del 2010

Diagrama Entidad –Relación

Generalmente todo modelo tiene una

Se denomina así debido a que precisamente

El modelo debe estar compuesto por:

8 de octubre del 2010

Estas tablas, pueden ser construídas de diversas maneras:

• Creando un conjunto de tablas iniciales y aplicar operaciones de normalización

• Convertir el diagrama e-r a tablas y posteriormente aplicar también operaciones de

La primer técnica fue de las primeras en existir y, como es de suponerse, la segunda al

• Lo anterior tiene otra ventaja, aún cuando se normalice de manera deficiente, se

rápido, fácil mantenimiento, portabilidad, facilidad de futuros mejoramientos, buen

Normalización es una serie de reglas que involucra análisis y transformación de las

8 de octubre del 2010

 Evitar la redundancia de los datos.

 Cada columna debe tener su nombre único.

8 de octubre del 2010

Diagrama Entidad Relación

---------------------------------------Creación de la base de Datos---------------------------------

CREATE DATABASE Campeonato_Ajedrez ON

8 de octubre del 2010

--Tabla de la relacion alojan--

8 de octubre del 2010

--Tabla relacion celebran--

Entradas nvarchar (20) NOT NULL ,

8 de octubre del 2010

--Tabla relacion juegan--

ADD CONSTRAINT PK_Codigo_sala PRIMARY KEY NONCLUSTERED

8 de octubre del 2010

ALTER TABLE dbo.Alojan WITH NOCHECK

ALTER TABLE dbo.celebran WITH NOCHECK

ALTER TABLE dbo.Juegan WITH NOCHECK

8 de octubre del 2010