UNIDAD III y IV

Conceptos Generales del entorno de las Bases de Datos:

Definición de Base de Datos
Se define una base de datos como una serie de datos organizados y relacionados entre sí, los cuales son recolectados y
explotados por los sistemas de información de una empresa o negocio en particular.
Las bases de datos proporcionan la infraestructura requerida para los sistemas de apoyo a la toma de decisiones y para los
sistemas de información estratégicos, ya que estos sistemas explotan la información contenida en las bases de datos de la
organización para apoyar el proceso de toma de decisiones ó para lograr ventajas competitivas. Por este motivo es importante
conocer la forma en que están estructuradas las bases de datos y su manejo.
Registros: es un tipo de dato estructurado formado por una colección finita de elementos no necesariamente homogéneos
llamados campos, normalmente relativos a una entidad particular. Cada campo se identifica por un nombre único llamado
identificador de campo conjunto de conceptos que tienen algo en común con la entidad descrita.
Entidades: cualquier objeto o evento acerca del cual alguien escoge o recolecta datos, puede ser un persona, cosa, etc. Objeto
real o abstracto (cosa) del que al menos queremos guardar información en la BD.(productos,clientes).
Sus características son:
Tiene existencia propia.
Se puede distinguir de los demás elementos de la BD.
Clases :
Fuertes -> Tienen existencias por si mismos.
Débiles -> Existen por otra entidad.

Relaciones: son asociaciones entre entidades, existen distintos tipos, uno a uno (un paquete de producto para cada producto),
uno a muchos (un médico para todos) y muchos a muchos (un estudiante puede tener muchos cursos y muchos estudiantes
pueden tener un curso)
Atributos: Un atributo de una relación o de una tabla corresponde a una columna de la tabla. Los atributos están desordenados y
se referencian por nombres y no por la posición que ocupan. Esto significa que no se puede, por ejemplo, hacer referencia al
tercer atributo de una relación. Todos los valores de los atributos son atómicos y una relación que satisfaga esta condición se
llama relación normalizada. Un atributo extrae sus valores desde un dominio simple. Formalmente, un atributo es una función que
se define entre un Dominio y un determinado tipo de Entidad de la base de datos. Dicha función asocia una ocurrencia de Tipo
de Entidad con un determinado elemento del dominio.
Llaves: es un registro que se usa para identificar un registro. Cuando identifica en forma única a un registro es llamada llave
primaria, (número de pedido), la llave secundaria si no es única. A un registro. Las llaves concatenadas es una clave construida
con una combinación de conceptos de datos.
Metadatos: Los metadatos describen a los datos, el nombre la longitud y composición de cada registro y pueden contener
restricciones acerca del valor de un concepto de datos.
Diagrama Entidad-Relación
Tipos de organización de Bases
de Datos:
Visión Lógica y Física: Cada usuario
ve los datos de forma diferente, el
modelo lógico debe ser
transformado en físico, involucrado
con la manera en que son accedidos,
guardados y relacionados.
Hay 3 tipos de bases de datos
estructurados lógicamente:
a) Estructuras de datos
jerárquicas: implican que una
entidad no puede tener más de una
entidad que la posea. Esta es una estructura basándose en ramificaciones donde una entidad puede poseer varias entidades
subordinadas las cuales se semejan a las ramas de un árbol. Podemos tomar como ejemplo de base de datos jerárquica a una
organización donde tenemos como entidad principal la Vice- Presidencia de Informática donde todas sus Gerencias son
subordinadas a la Vice Presidencia y a su vez cada Departamento es subordinado pero de una gerencia en específico.
b) Estructuras de datos en red: permite a cualquier entidad tener cualquier cantidad de subordinados o superiores,
conectados con enlaces de red, alivian los problemas de las estructuras jerárquicas. Una estructura en forma de red permite
que cualquier entidad cuente con cualquier número de subordinados o superiores. Las entidades se conectan mediante el uso de
enlaces de red, los cuales son datos comunes a ambas entidades conectadas.
Esta estructura se caracteriza por el enlace común de varias entidades.
Existe estructura en red simple y compleja.
Una de las ventajas de este tipo de estructura es que en un mismo dato pueden ser utilizados por distintas entidades.
Una de sus desventajas es que puede existir redundancia en los datos existentes.
Representamos al mundo real como registros lógicos que representan a una entidad y que se relacionan entre sí por medio de
flechas.
c) Estructura de datos relacional: consiste en una o más tablas de dos dimensiones a las que se les llama relaciones, los
renglones contienen registros y las columnas atributos. Es bastante simple mantener estas tablas. Una de las ventajas las
preguntas ad hoc son manejadas eficientemente. Para que estas estructuras sean eficientes deben ser normalizadas.
Una base de datos relacional consiste en una o más tablas bidimensionales, las cuales se refieren como relaciones. Los renglones
de las tablas representan los registros y las columnas contienen los atributos. Podemos llamar también relacional a la base de
datos construida por relaciones entre dos tablas o más.
Se caracteriza por trabajarse en forma de matriz, es decir, por filas y columnas.
Entre sus ventajas tenemos que; es mas eficiente la manera de manejar consultas especificas y es más factible para el
crecimiento de la base de datos.
Representa al mundo real mediante tablas relacionadas entre sí por columnas comunes.
Componentes principales de una base de datos
Datos. Los datos son la Base de Datos propiamente dicha. La cual es ingresada ó proporcionada por los usuarios del proceso de
negocio.
Hardware. El hardware se refiere a los dispositivos de almacenamiento en donde reside la base de datos, así como a los
dispositivos periféricos (unidad de control, canales de comunicación, etc.) necesarios para su uso.
Software. Está constituido por un conjunto de programas que se conoce como Sistema Manejador de Base de Datos (DMBS:
Data Base Management System). Este sistema maneja todas las solicitudes formuladas por los usuarios a la base de datos.
Usuarios. Existen tres clases de usuarios relacionados con una Base de Datos:
El programador de aplicaciones, quien crea programas de aplicación que utilizan la base de datos.
El usuario final, quien accesa la Base de Datos por medio de un lenguaje de consulta o de programas de aplicación.
El Administrador de la Base de Datos (DBA: Data Base Administrator), quien se encarga del control general del Sistema de Base
de Datos.

Diseño de las bases de datos.

El primer paso para crear una base de datos, es planificar el tipo de información que se quiere almacenar en la misma, teniendo
en cuenta dos aspectos: la información disponible y la información que necesitamos.
La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la gestión efectiva de la misma. El
diseño de la estructura de una tabla consiste en una descripción de cada uno de los campos que componen el registro y los
valores o datos que contendrá cada uno de esos campos.
Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definición de un
campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc.
Los registros constituyen la información que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el
apellido del paciente y la dirección de este. Generalmente los diferente tipos de campos que su pueden almacenar son los
siguientes: Texto (caracteres), Numérico (números), Fecha / Hora, Lógico (informaciones lógicas si/no, verdadero/falso, etc.
imágenes.
En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es determinar claramente los campos
necesarios, definirlos en forma adecuada con un nombre especificando su tipo y su longitud.

Manejadores o lenguajes de bases de datos:

El SQL Server Manager es un sistema y herramienta de administración de bases de datos para Servidores SQL. Con una
interfaz gráfica de usuario amigable sobre Windows, que por medio de iconos se representa a las diferentes tareas que suele
desempeñar un administrador. Entre estas tareas podemos encontrar la administración de uno o más servidores SQL, de
recursos físicos, de bases de datos, de objetos en la base de datos.
El Sistema de Gestión de Bases de Datos (SGBD) Consiste en un conjunto de programas, procedimientos y lenguajes que nos
proporcionan las herramientas necesarias para trabajar con una base de datos. Incorporar una serie de funciones que nos
permita definir los registros, sus campos, sus relaciones, insertar, suprimir, modificar y consultar los datos.
Microsoft SQL Server 7.0 constituye un lanzamiento determinante para los productos de bases de datos de Microsoft,
continuando con la base sólida establecida por SQL Server 6.5. Como la mejor base de datos para Windows NT, SQL Server es
el RDBMS de elección para una amplia gama de clientes corporativos y Proveedores Independientes de Software (ISVs) que
construyen aplicaciones de negocios. Las necesidades y requerimientos de los clientes han llevado a la creación de innovaciones
de producto significativas para facilitar la utilización, escalabilidad, confiabilidad y almacenamiento de datos.
ORACLE Es el manejador de base de datos relacional que hace uso de los recursos del sistema informático en todas las
arquitecturas de hardware, para garantizar su aprovechamiento al máximo en ambientes cargados de información.
Informix-4GL ofrece herramientas para crear menús, formularios de entrada de datos y generadores de listados. Será
necesario definir estas mismas herramientas manteniendo, a ser posible, la sintaxis original. En principio se generarán
aplicaciones que funcionen en modo texto, dejando para una futura ampliación la generación de aplicaciones en entornos
gráficos.
Existe software especializado en bases de datos, los llamados servidores de bases de datos, los tres mas comunes son SQL-
SERVER de Microsoft, ORACLE Server de Oracle, MYSQL Open Source, en estos casos la base de datos( o conjunto de tablas
que tienen relaciones comunes entre si) residen en un servidor de bases de datos especializado en algún lugar cercano o lejano
en una red chica, mediana o grande.
Otros paquetes o software mas pequeños y comunes también reciben el nombre de DBMS(DATA BASE MANAGEMENT
SYSTEM) o sistemas administradores de bases de datos.
Este tipo de software se especializa en la creación, mantenimiento, seguridad, privacidad, etc. de un conjunto de tablas o mejor
dicho una base de datos, DBMS comunes son access, postgres, fox, clipper, etc.
Recordar que una base de datos es en principio un conjunto de tablas que tienen y mantienen relaciones entre si.
La segunda etapa consiste en construir la aplicación o aplicaciones que ya tendrán acceso o podrán manipular los datos
contenidos en la tabla, estas aplicaciones se escriben usando ya sea lenguajes clásicos de programación como BASIC, PASCAL,
COBOL, CBUILDER, DELPHI, JAVA, VBSCRIPT, PERL, JSCRIPT, CSHARP, etc.

Pasos necesarios para elaborar un sistema con base de datos

1)Identificación de problemas, oportunidades y objetivos.
• En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificación de los
problemas, de las oportunidades y de los objetivos. Esta fase es crucial para el éxito del resto del proyecto, pues
nadie estará dispuesto a desperdiciar su tiempo dedicándolo al problema equivocado.
• La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto
con los otros miembros de la organización hará notar los problemas. Muchas veces esto ya fue realizado previamente:
y por ello. es que se llega a invitar al analista.
2) Determinación de los requerimientos de información.
• La siguiente etapa que aborda el analista, es la determinación de los requerimientos de información a partir de los
usuarios particularmente involucrados. Para identificar los requerimientos de información dentro de ¡a empresa,
pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por
la organización, la entrevista, los cuestionarios: la observación de la conducta de quien toma las decisiones, así como de
su ambiente y también el desarrollo de prototipos.
• En esta etapa el analista hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus
tareas. Puede ver, cómo varios de los métodos para establecer las necesidades de información, lo obligan a
relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la
organización y de sus objetivos. En ocasiones, se llegan a concluir sólo las primeras dos etapas del ciclo de desarrollo
de los sistemas. El analista es el especialista que emprende esta clase de estudios.
3) Análisis de las necesidades del sistema.
La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las necesidades propias del sistema. Una vez
más, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas.
Estas incluyen el uso de los diagramas de flujo de datos (DFD)que cuentan con una técnica estructurada para representar
en forma gráfica la entrada de datos de la empresa, los procesos y la salida de la información. A partir del diagrama de
flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, así como sus
especificaciones, si son alfanuméricos, descripción, clave primaria, entre otros.
4) Diseño del sistema recomendado.
• En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa la información que recolectó con
anterioridad y elabora el diseño lógico del sistema de información. El analista diseña procedimientos precisos de
captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. El analista también
diseña accesos efectivos al sistema de información, mediante el uso de las técnicas de diseño de formularios y de
pantallas.
• Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario.
5) Desarrollo y documentación del software
• En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con los programadores para desarrollar todo
el software original que sea necesario. Dentro de las técnicas estructuradas para el diseño y documentación de!
software se tienen: el método HIPO, los diagramas de flujo. los diagramas Nassi-Schneiderman, los diagramas
Warnier-Orr y el pseudocódigo. Aquí es donde, el analista de sistemas transmite al programador los requerimientos de
programación.
• Durante esta fase, el analista también colabora con los usuarios para desarrollar la documentación indispensable del
software, incluyendo los manuales de procedimientos. La documentación le dirá al usuario como operar el software, y
así también, qué hacer en caso de presentarse algún problema.
6) Pruebas y mantenimiento del sistema.
• El sistema de información debe probarse antes de utilizarlo. E! costo es menor si se detectan los problemas antes cié
la entrega del sistema. El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración
con el analista de sistemas. En un principio, se hace una serie de pruebas, con datos tipo, para identificar las posibles
fallas del sistema: más adelante, se utilizarán los datos reales.
 • El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa: y después, esta función se
realizará de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una
buena parte de la rutina del programador, que para las empresas llegan a simplificar importantes sumas de dinero. Sin
embargo, el costo del mantenimiento disminuye de manera importante cuando el analista aplica procedimientos
sistemáticos en el desarrollo de los sistemas.
7) Implantación y evaluación del sistema.
• En esta última etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de información. Esto incluye el
adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales, la supervisión
del adiestramiento es una responsabilidad del analista de sistemas. Más aún, el analista necesita planear la suave
transición que trae consigo un cambio de sistemas.
• Aunque la evaluación del sistema se plantea como parte integrante de la última etapa del ciclo de desarrollo de los
sistemas; realmente, la evaluación toma parte en cada una de las etapas. Uno de los criterios fundamentales que debe
satisfacerse, es que el futuro usuario utilice el sistema desarrollado.
Generalidades:
Analizamos que para la realización de una Base de datos la creación de consultas de base de datos consta de archivos que
permiten realizar muchas tareas diferentes con los datos que se pueden ver. También se pueden utilizar para controlar los
registros que visualiza Base de datos la consulta no contiene información de base de datos, si no tan solo las instrucciones
necesarias para seleccionar los registros y campos requeridos de una base de datos.
Es muy importante el observar el proceso que se sigue en la organización para determinar los requerimientos que se necesitan
para la elaboración de un sistema y para ello se recurren a varias técnicas de recopilación de información para que el proyecto
satisfaga las necesidades de los usuarios finales que es el que esta en pleno contacto con él.
Algunos de los aspectos aprendidos y que de gran peso es la base de datos su definición, requerimiento, ventajas y
características donde podemos decir que la base de datos: Es una colección de datos o información usados para dar servicios a
muchas aplicaciones al mismo tiempo.
En cuanto al requerimiento podemos decir que cumple las mismas tareas de análisis que del software y tiene como característica
relacionar la información como vía organización y asociación donde la base de datos tiene una ventaja que es utilizar la
plataforma para el desarrollo del sistema de aplicación en las organizaciones.
Otro aspectos importante seria el diseño y creación de la base de datos, donde existen distintos modos de organizar la
información y representar las relaciones entre por datos los tres modelos lógicos principales dentro de una base de datos son el
jerárquico, de redes y el relacional, los cuales tiene ciertas ventajas de procesamiento y de negocios.
Otro punto necesario es la clase de bases de datos las cuales son, base de dato documental, base de datos distribuidas y base
de datos orientadas a objetos e hipermedia y tienen como función derivar, almacenar y procesar datos dentro de una
información.
MODELOS DE DATOS y MODELOS DE
OBJETOS RELACIONALES.
Los modelos de datos son medios formales para representar los datos asociados a una situación real y para manipular tal
representación. Tal como se ilustra a continuación. Las componentes de todo modelo de datos son las siguientes:

Los modelos de datos se pueden clasificar en:

• modelos de alto nivel o semánticos
 • modelos de bajo nivel o básicos.

Los modelos semánticos capturan un mayor significado de los datos e intentan representar la estructura real de los datos
independientemente de las características de almacenamiento, es decir ellos están orientados a las aplicaciones. Existen, hoy en
día, numerosos y muy variados modelos semánticos, entre ellos se encuentran: el modelo Entidad-Relación de P. Chen en [Che-
76], el modelo Entidad-Relación-Extendido (ERE) de Teorey et al. en [T-86] y el modelo IFO propuesto por Abiteboul en [ABI-
]. De modelos anteriores solo será tratado el segundo de ellos en detalle más adelante.
Los modelos básicos constituyen el grupo de modelos que han sido diseñados orientándose al computador, sobre ellos se han
desarrollado la mayoría de los SMBD. Ellos son: el modelo de jerárquico, el modelo redes, el modelo relacional, el modelo
orientado por objetos y el objeto-relacional. Al igual que los anteriores, ellos serán vistos en detalle en las secciones siguientes.

II.1.- Modelos semánticos

Muchos modelos semánticos han sido propuestos, pero pocos de ellos han atraído el interés de los desarrolladores de sistemas
de base de datos, esto tal vez es debido a la complejidad de tales modelos y a su dificultad para ser plasmados con los modelos
básicos actuales. La mayoría de los conceptos del modelado semántico de datos han sido muy bien representados en el modelo
ERE, el cual goza de gran prestigio y popularidad en el ambiente comercial, jugando un rol muy importante en la mayoría de las
herramientas CASE (Computer Aided Software Engineering).

Modelo Entidad-Relación-Extendido(ERE)
El modelo Entidad-Relación (E-R) propuesto por P. Chen en [CHE-76] fue la primera versión del modelo ERE. Dicha primera
versión se fue modificando con el paso del tiempo debido a la necesidad de tener constructos mas adecuados para la gran
diversidad de aplicaciones que existen hoy en día en el área de las bases de datos.
Así, la proposición de P. Chen ha sido modificada y enriquecida semánticamente por otros autores. Debido al gran poder
expresivo que tiene hoy en día, este modelo es el primero en popularidad y en utilización en la etapa de diseño conceptual de
base de datos. En este modelo se emplea el enfoque de diseño de arriba-hacia-abajo y los conceptos de abstracción de datos.
El modelo ERE representa la información por medio de tres conceptos básicos: entidades, relaciones y atributos. Su principal
objetivo es producir vistas conceptuales de los datos de la aplicación. Cada vista se expresa en términos de los conceptos
básicos ilustrados en los diagramas ERE. El modelo está basado en la teoría de conjuntos y en la de las relaciones.
Entidad, según el diccionario Larousse, es "lo que constituye la esencia del ser // colectividad considerada como una unidad".
Para los efectos de las aplicaciones en base de datos

Una entidad puede ser un objeto como: una casa, una planilla, un carro, etc.; un sujeto
como una persona; o un evento o actividad como: un partido de football, un viaje, etc.

Las entidades se agrupan en conjuntos denominados conjunto entidad y se representan en los diagramas ERE como un
rectángulo con el nombre del conjunto entidad dentro. La figura II.2 muestra un ejemplo de dicha representación.

Figura II.2. Conjuntos entidad en los diagramas ERE.

Una misma entidad puede pertenecer a varios conjuntos entidad. Por ejemplo, un médico hospitalizado pertenece a los conjuntos
entidad paciente y médico.
Una relación es una asociación entre dos o más entidades de un mismo tipo o de tipos diferentes. Las relaciones o asociaciones
también se agrupan en conjuntos, recibiendo el nombre de conjunto relación. Los conjuntos relación se representan
gráficamente por medio de un rombo que encierra el nombre asociado al conjunto relación especificado. Ejemplos de estos son:
propietario que asocia un automóvil a un empleado, dicta que asocia un profesor con una asignatura, etc. La figura II.3 ilustra el
conjunto relación propietario.

Figura II.3. Conjunto relación en los diagramas ERE.

La figura anterior también muestra los tipos de correspondencia entre los conjuntos entidad asociados por el conjunto relación
propietario y la cardinalidad de dicha relación.
Los tipos de correspondencia se refieren al número de entidades involucradas en la relación, en un sentido y en el sentido
contrario. Así:
1:1 Una entidad del conjunto entidad 1 (C-E1) está asociada a una única entidad del C-E2.
 1:N o N:1 Cada entidad del C-E1 está asociada a cero, una o más entidades del C-E2 o viceversa.
N:M Cada entidad del C-E1 está asociada a cero, una o más entidades del C-E2 y viceversa.
La cardinalidad de la relación o asociación entre dos entidades expresa el número mínimo y máximo de entidades relacionadas a
través del conjunto relación, así en la figura II.3 un empleado puede ser propietario de ninguno o hasta 4 automóviles y un
automóvil puede tener como propietario uno y solo un empleado, esto implica que en la BD no hay ningún automóvil sin
propietario, pero si hay empleados que no tienen automóvil.
Una entidad se describe por medio de sus atributos y una relación puede también ser descrita por medio de atributos. Un
atributo es una característica o propiedad específica de una entidad o de una relación. Cada atributo se identifica con un
nombre y se le asocia un dominio de valores posible que puede tener en un momento particular. Los atributos se expresan en el
modelo E-R con nombres que etiquetan las aristas entre el conjunto entidad o relación a que pertenecen y el dominio asociado al
mismo. Los dominios se expresan con óvalos identificados con un nombre, que es el nombre del dominio. La figura II.4 completa
el diagrama mostrado en la figura anterior.

Figura II.4. Atributos, dominios y claves en un diagrama ERE.

Una clave o llave de un conjunto entidad o relación es un grupo de uno o más atributos que identifican unívocamente cada
entidad o relación del conjunto. La clave de un conjunto relación es siempre la concatenación de las claves de los conjuntos
entidad que ella asocia. En la figura II.4 se observan las claves de cada conjunto entidad y de la relación propietario.
Un conjunto entidad es débil si su existencia depende de otro conjunto entidad. De igual manera, un conjunto relación es débil
si él depende de otro. La figura II.5 presenta un ejemplo de diagrama donde se observan ambos casos. Un objeto del conjunto
entidad objeto existe en la BD si existe la entidad vista del conjunto entidad vista. Asimismo, la relación clave-obj existe si la
relación vista-obj existe.

Figura II.5. Entidades y relaciones débiles en un diagrama ERE.

Un conjunto entidad puede especializarse en otros conjuntos entidad mostrando los diferentes tipos de ese conjunto entidad.
Asimismo, varios conjuntos entidad pueden generalizarse en un conjunto entidad genérico, en cuyo caso el proceso de
abstracción realizado se denomina generalización y en el primer caso se denomina especialización. Sin importar el proceso de
abstracción realizado, el hecho es que existe en el diagrama un conjunto entidad que es una superclase de otros conjuntos
entidad denominados subclases, los cuales heredan de la superclase todos sus atributos. La herencia puede ser simple o
múltiple, bien sea que herede de un solo conjunto entidad o de varios, respectivamente. La herencia también puede ser parcial o
total, en caso que la extensión de la superclase tenga un número de entidades diferente a la suma del número de entidades de
sus subclases o que ese número sea igual, respectivamente. Gráficamente la herencia parcial se representa con una arista
simple, la total con doble arista y la conexión entre superclases y subclases se realiza con un círculo si hay más de una subclase,
llevando siempre un arco que intersecta la arista para indicar cual es la subclase. Se puede dar el caso que las entidades de las
extensiones de las subclases se solapen, lo cual se expresa en el diagrama colocando una o en el círculo, indicando la conjunción
de las entidades, si ese no es el caso, pues las extensiones de las subclases son disjuntas, entonces se coloca una d indicando la
disyunción de las extensiones.
Un caso especial denominado categoría se presenta cuando una entidad de un conjunto entidad puede ser una entidad heredada
de 2 o más conjuntos entidad diferentes, pero cuyos atributos no se concatenan, pues la entidad en la categoría puede ser una y
solo una de las entidades de cualquiera de las superclases. La categoría se presenta en el diagrama colocando en el círculo una U.
La figura II.6 muestra dos ejemplos de categorías, uno donde un dueño puede ser una persona, un banco o una compañía y el otro
donde una propiedad puede ser un edificio o un lote de terreno.

Figura II.6. Categorías y herencia en diagramas ERE.

II.2. Modelos básicos
Son los modelos sobre los que se han desarrollado la mayoría de los SMBD, estos son:

• Jerárquico y redes
• Relacional
• Orientado por objetos
• Objeto-Relacional

II.2.1. Modelo relacional

Fue propuesto por E. Codd en 1970 [Cod-70] cuando trabajaba para IBM-San José. El modelo está basado en la teoría de
normalización de las relaciones, que permite eliminar el comportamiento anormal de las relaciones, luego de actualizaciones, así
como el control de la redundancia de datos.

Conceptos básicos
Los conceptos básicos del modelo son:
Dominio:
es un conjunto de valores
Ejm: D1 = {´rojo`, ´verde`, ´negro`, ´azul`} D2 = {`ford´, ´chevrolet`, ´fiat`, ´toyota`, ´renault`}
Relación: es un subconjunto del producto cartesiano de una lista de dominios, no necesariamente disjuntos.
Ejm: R1 = {(´rojo`,`ford´), (´verde`,`ford´), (´negro`, ´chevrolet`), (´azul`, ´toyota`)}
R2 = {(´fiat`, ´verde`)}
R3 = { }

R D1 D2

´verde` ´ford`

´azul` ´fiat`
Atributo:
es la columna de una relación identificada con un nombre.

Ejm:

R color marca

´verde` ´ford`

´azul` ´fiat`

Esquema de una relación o de tabla:

es el nombre de la relación seguido de la lista de sus atributos con sus dominios. Un esquema de relación se puede representar
por intensión o por extensión.
Esquema de Carro por intensión:
Carro(placa, marca, modelo, color)
Esquema de Carro por extensión:

Tabla  columna 

Carro Placa marca modelo Color

fila o tupla  ´LGR889` ´toyota` ´corollaXL` ´azul`

´LAB110` ´ford` ´sierra280es` ´verde`

´XSG230` ´fiat` ´siena` ´azul`

Base de datos relacional:

es una base de datos cuyo esquema es un conjunto de esquemas de relación de diferente nombre cada una, y donde sus
ocurrencias son las tuplas de esas relaciones.

2.2. Reglas de formación

1. Cada relación o tabla contiene un solo tipo de fila o tupla.

2. Cada tupla tiene un número fijo de atributos o columnas.
3. No se permiten atributos compuestos o grupos repetitivos.
4. Cada tupla es única y se identifica con su clave primaria.
5. Un atributo o grupo de ellos que identifiquen unívoca e inequívocamente cada tupla de la relación es una clave
candidata.
6. La clave primaria de una relación se selecciona entre las claves candidatas.
7. Si un atributo A  R1 es también la clave primaria de R2, entonces A es un atributo foráneo de R1.
8. El orden de las tuplas en la relación es irrelevante.
9. Los valores de los atributos deben pertenecer al dominio de cada atributo definido en ella.
10. Un mismo dominio puede ser usado por diferentes atributos.
11. A partir de una o más tablas se pueden producir nuevas tablas diferentes mediante el uso de las operaciones del
álgebra relacional.

2.3. Reglas de integridad

• De la relación: ningún componente de un valor de los atributos que conforman la clave primaria puede ser nulo.
• De referencia: sea A la clave primaria de R1 y también un atributo foráneo de R2, entonces para toda tupla de R2
donde A  nulo debe existir la tupla correspondiente en R1.
• De los valores de un atributo: son los predicados definidos por el administrador de bases de datos sobre los valores
de los atributos usando el lenguaje de definición de datos.

Ejemplo:
fechaInicio  fechaFin restricciones de integridad de
fechaInscripción  fechaInicio los valores de los atributos.
 Semestre Código fechaInicio fechaFin fechaInscripción

tupla  ´A98` 02/03/98 17/07/98 22/2/98

´B98` 14/09/98 30/01/99 07/09/98

´A99` 15/03/99 23/07/99 08/03/99

Ejemplo de una base de datos relacional

Cliente( codCli, nombre, balance, límiteCrédito, descuento)
Envio( dirección, codCli)
Pedido( codPed, línea, dirEnvio, codArt, cantidadPedida, cantidadEnviada)
Artículo( codArt, nomArt, descripción)
Inventario( codArt, codPlanta, cantidadExistencia, riesgo)

Atributo Descripción Dominio

CodCli Código del cliente Cadena(4)

Nombre Nombre del cliente Cadena(40), sub(nombre,i,1) {letras}

Balance Balance actual de la cuenta del cliente Real

límiteCrédito Límite de crédito actual del cliente Real siempre positivo

Descuento Descuento actual que se le aplica al cliente Real siempre positivo

dirección, dirEnvio Dirección de envío del cliente (un cliente puede Cadena(80),sub(dirección,i,1)  {letras}  {/,-,’}
tener varias) con i desde 1 hasta 80

CodPed Código de pedido Cadena(6)

Línea Línea del pedido Entero corto siempre positivo

cantidadPedida Cantidad pedida del artículo Entero siempre positivo

cantidadEnviada Cantidad enviada del artículo Entero siempre positivo

CodArt Código del artículo Cadena(6)

NomArt Nombre del artículo Cadena(20),sub(nomArt,i,1) {letras}

Descripción Descripción del artículo Cadena(255), sub(descripción,i,1) {letras}

CodPlanta Código de la planta que tiene el artículo Cadena(2)

CantidadExistencia Cantidad actual en existencia del artículo Entero siempre positivo

Riesgo Cantidad mínima del artículo en inventario Entero siempre positivo

Restricción de integridad: cantidadPedida  cantidadEnviada  cantidadExistencia

II.2.3.1. Restricciones de integridad

La integridad de los datos en bases de datos accedidas por procesos concurrentes debe ser asegurada, mediante la
aplicación de restricciones y reglas que aseguren la concordancia de los datos que la base de datos modela con los del
mundo real.
Restricciones de integridad: Son aserciones que deben verificar los datos en instantes determinados.
Bases de datos coherentes: Son bases de datos donde el conjunto de restricciones de integridad (explícitas o
implícitas) se respeta a todo lo largo de la vida útil de la BD.

Tipos de restricciones de integridad: Se tienen ocho tipos que son los siguientes:
Restricciones de dominio o integridad de dominio: Están referidas al tipo de dato del atributo o columna. El valor que se puede
asignar a una columna debe estar en el dominio especificado para dicha columna. Se permite a un dato estar marcado para
contener un valor especial definido por el diseñador de la BD (NoDefinido), no contener valor alguno o contener el valor nulo si:
Existe la posibilidad de desconocer la información (nulo aplicable)
No tiene sentido asignar un valor del dominio (nulo inaplicable)
Ejemplo: cant es de tipo Entero siempre positivo.

Restricciones de rango o integridad de columna: Se refiere al intervalo de variación de los valores del dominio del atributo y
de los tipos de datos definidos en el SMBD. Ejemplo: edad es de tipo Entero siempre positivo entre 0 y 120.
Integridad de entidad o de dependencias funcionales: Se refiere al hecho de tener un atributo que está determinado por uno
o varios atributos. Estas restricciones están aseguradas con la normalización de las tablas de la BD. Ningún componente de una
clave primaria puede contener valores nulos. Ningún componente de una clave foránea debe permitir un valor nulo por inaplicable,
aunque si puede permitir valor nulo por desconocimiento de información. Ejemplo: cedula determina edad.
Dependencias multivaluadas: Son aquellas donde uno o varios atributos multideterminan un atributo. Estas están aseguradas
con la normalización de las tablas de la BD. Ejemplo: cedulaEstudiante multidetermina deportePractica.
Dependencias de Combinación: Al igual que las anteriores, constituyen restricciones semánticas sobre los atributos de una
relación. Están relacionadas con las interrelaciones de grado superior a 2 definidas en el modelo E/R. Constituyen una
generalización, es decir, una dependencia funcional es una dependencia multivaluada y toda dependencia multivaluada es también
una dependencia de combinación, pero la inversa no siempre es cierta. Ejm.: R: {Profesor, Asignatura, Texto},
Profesor à Asignatura ó Asignatura à Texto ó Texto à Profesor
Integridad referencial: Son las dependencias de inclusión en varias tablas o de claves foráneas. Para cada clave foránea debe
existir un valor equivalente de una clave primaria y en el mismo dominio. Ejemplo: Se tienen las tablas Carro(placa, modelo,
color) y ModeloMarca(modelo, marca), en ellas observamos que el atributo modelo es clave en la tabla ModeloMarca y está
incluida en la tabla Carro, por tanto el atributo modelo es una clave foránea en la relación Carro.
Restricciones aritméticas: Son las expresiones aritméticas que deben cumplir algunos atributos de una tabla o que involucra a
varias tablas de la BD. Ejemplo: En la BD formada por las tablas siguientes:
Producto(codPro, nomPro, cantExistencia, color)
Venta(codVen, nomCli, codProVen, cantVen, fechaVen)
Compra(codCom, fechaCom, codProCom, cantCom, nomProveedor)
Para todo producto identificado con su código codPro de la tabla Producto, la cantExistencia debe ser mayor que la
cantidad vendida cantVen para el producto codProVen, ya que no se puede vender una cantidad de producto mayor que la
que se tiene en existencia.
Valores invariantes que no son posibles de expresar en el esquema: Ejemplo: Tomando la BD descrita anteriormente, se
tiene que en todo momento la cantidad comprada menos la cantidad vendida debe ser igual a la cantidad en existencia (cantCom
- cantVen = cantExistencia), para cada producto presente en la BD.
Restricciones temporales: Son aquellas aserciones que deben ser cumplidas periódicamente o en momentos específicos.
Ejemplo: En una BD de trasacciones bancarias al finalizar cada mes, el saldo de cada cuenta debe ser igual a la suma de
depósitos en la cuenta menos la suma de los retiros de la cuenta.
Normalización
La normalización es el proceso de organizar los datos en una base de datos. Incluye desde la creación de tablas y el
establecimiento de relaciones entre ellas hasta el diseño de las reglas de protección de datos y la creación de bases de datos
más flexibles gracias a la eliminación de redundancias y dependencias incoherentes.
Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si es necesario cambiar datos que
aparecen en más de un sitio, el cambio deberá ser exactamente igual en todos estos sitios. Por ejemplo, un cambio de dirección
de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y en ningún otro lugar de la
base de datos.
¿Qué es una "dependencia incoherente"? Aunque para un usuario puede resultar intuitivo buscar la dirección de un determinado
cliente en la tabla Clientes, es posible que no tenga sentido buscar en esa misma tabla el sueldo del empleado que atiende a
dicho cliente. El salario del empleado está relacionado con el empleado (es decir, existe una dependencia entre ambos), por lo
que debe moverse a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso a los datos, ya que la ruta de
acceso a los mismos puede estar rota o no encontrarse.
Existen unas cuantas reglas para la normalización de bases de datos. Cada regla se denomina "forma normal". Si se cumple la
primera regla, se dice que la base de datos está en la "primera forma normal". Si se cumplen las tres primeras reglas, se
considera que la base de datos está en la "tercera forma normal". Aunque existen otros niveles de normalización, se considera
que la tercera forma normal es el máximo nivel necesario para la mayoría de las aplicaciones.
Como sucede con muchas reglas formales y especificaciones, los escenarios del mundo real no siempre permiten cumplir a la
perfección estas reglas. En general, la normalización exige utilizar tablas adicionales y algunos usuarios consideran que es algo
molesto. Si decide no cumplir alguna de las tres primeras reglas de normalización, asegúrese de que su aplicación anticipe
cualquier posible problema, como datos redundantes y dependencias incoherentes.
Formas normales
El objetivo de las tres primeras formas normales es permitir la descomposición de relaciones sin pérdida de información, a
partir de las DFE y obtener así el esquema conceptual relacional normalizado.
• Primera forma normal (1FN): Una relación está en 1FN si todo atributo contiene un valor atómico.
Ejemplo:
• Persona(cedula, nombre, apellido, sexo, telefono, direccion)
los primeros cinco atributos son atómicos y el atributo direccion puede ser considerado atómico en aquellas
aplicaciones donde esta columna no va a ser utilizada como un atributo de búsqueda, lo que implica que la
relación Persona está en 1FN.
• Estudiante(cedula, apellido, nombre, escuela, materias, notas)
es claro que los primeros cuatro atributos son atómicos, pero también es claro que los dos últimos no lo
están, por lo tanto la relación no está en 1FN. Para convertirla a 1FN se proyecta en dos relaciones,
obteniendo:
Estudiante(cedula, apellido, nombre, escuela)
Cursa(cedula, materia, nota)
• Segunda forma normal (2FN): Una relación está en 2FN si y solo si:
1. la relación está en 1FN
2. todo atributo que no pertenece a una clave no puede depender de una parte de esa clave.
Ejemplo:
• Proveedor(codProv, codArt, dirProv, precio)
Ella está en 1FN considerando la dirección como una columna atómica, pero dadas las DFE siguientes:
(codProv, codArt)  precio y codProv  dirProv, ella no está en 2FN, pues hay un atributo no clave (dirProv)
que depende de una parte de la clave. Para normalizarla se proyecta en dos relaciones:
Proveedor(codProv, dirProv)
ProveeArticulos(codProv, codArt, precio)
• Carro(placa, marca, modelo, color)
está en 2FN.
La segunda forma normal permite eliminar las redundancias para que ningún atributo esté determinado por una parte de una
clave.
• Tercera forma normal (3FN): Una relación está en 3FN si y solo si:
1. la relación está en 2FN
2. todo atributo que no pertenece a la clave no depende de un atributo que no es clave.
Ejemplo:
• Carro(placa, marca, modelo, color)
está en 2FN, pero no en 3FN ya que se tiene la DFE modelo  marca. Para normalizarla se proyecta en dos
relaciones:
Carro(placa, modelo, color)
ModelosDeCarros(modelo, marca)
La tercera forma normal permite asegurar la eliminación de redundancias debidas a las dependencias transitivas.
Un esquema normalizado hasta 3FN debe cumplir con el juramento siguiente:

• Forma normal de Boyce-Codd (FNBC): Una relación está en FNBC si y solo si las solas DFE son aquellas dentro de las
cuales una clave determina un atributo.
 Ejemplo:
Examen(cedEst, codMat, cedProf, nota) está en 3FN
(cedEst, codMat)  cedProf no está en FNBC si
cedProf  codMat cada profesor dicta
(cedEst, codMat)  nota una única materia
para resolver el problema se proyecta para que cumpla con la FNBC
Examen(cedEst, codMat, nota)
Dicta(codMat, cedProf)
No se preserva la DFE (cedEst, codMat)  cedProf
En general, la descomposición en FNBC es sin pérdida pero NO preserva las DFE, después ellas pueden obtenerse por
reunión o producto.
• Dependencias multivaluadas (DM): Sea R(A1, A2, ..., A n) y X e Y dos subconjuntos de atributos de {A1, A2, ..., An}. Se
dice que X -» Y, si dados los valores de X hay un conjunto de valores Y asociados y este conjunto es independiente de
otros atributos Z = R – X – Y de R.
Las DM caracterizan la independencia entre Y y Z correlacionadas por X.
Las DF son un caso particular de las DM, por lo cual X  Y  X -» Y
• Dependencias multivaluadas elementales (DME): Una DME es una DM X -» Y de una relación R tal que:
a. Y no es vacío y es disjunto de X
b. R no contiene otra DM del tipo X’ -» Y’ tal que X’  X y Y’  Y
Ejemplo: EstMatDeporte (nroEst, codMat, deporte)
EstMatDeporte nroEst codMat Deporte
105 ‘PD10’ ‘tennis’
105 ‘PD10’ ‘natación’
145 ‘AL10’ ‘tennis’
145 ´FI20’ ´futbol`
nroEst -» codMat, nroEst-» deporte, pues un estudiante puede cursar varias materias y puede practicar varios
deportes, pero codMat es independiente de deporte y en este caso solo están correlacionados a través de nroEst.
• Cuarta forma normal (4FN): Una R está en 4FN si y solo si las solas DME son aquellas donde una clave determina un
atributo. Una R en 4FN está en 3FN y en FNBC.
Ejemplo: EstMatDeporte (nroEst, codMat, deporte) no está en 4FN, por lo que se proyecta según sus DME como:
Cursa(nroEst, codMat)
Practica(nroEst, deporte)
• Teorema de Fagin (1979): R(A, B, C) se puede descomponer sin pérdida en R1(A, B) y R2(A, C) si y solo si se cumplen
en R las DM A -» B | C. Demuestra que toda R tiene una descomposición, no siempre única, en 4FN sin pérdida de
información.
Ejemplo: Curso(nomCur, prof, texto)

Curso nomCur Prof Texto

‘Estadística’ ‘Perez’ ‘Estadística I’

‘Estadística’ ‘Perez’ ‘Introducción a la estadística’

‘Estadística’ ‘Mendez’ ‘Estadística I’

‘Estadística’ ‘Mendez’ ‘Introducción a la estadística’

nomCur -» prof, nomCur-» texto

Se proyecta como:
TextoMateria(nomCur, texto)
Dicta(nomCur, prof)
• Dependencias de productos (DP): Existen relaciones que no es posible descomponerlas en 2 relaciones, pero si en 3, 4
o más relaciones. Sea R(A1, A2, ..., An) y X1, X2, ..., Xm subconjuntos de {A1, A2, ..., An}. Se dice que existe una DP
simbolizada por *{X1, X2, ..., Xm} si R es el producto de sus proyecciones sobre X1, X2, ..., Xm, es decir si
R =  X1( R )  X2( R ) ...  Xm( R )
Ejemplo: Si el proveedor #E suministra la pieza #P y en el proyecto #J se usan piezas #P y el proveedor #E
suministra piezas al proyecto #J, entonces #E suministra #P al proyecto #J. Suministro(#E, #P, #J) está en 4FN

Suministro #E #P #J
 E1 P1 J2

E1 P2 J1

E2 P1 J1

E1 P1 J1

No está en 5FN pues #E -» #P, #P -» #J, #J -» #E, no es posible descomponerla en 2 relaciones, pero si es posible
en 3 relaciones, así:

R1 #E #P R2 #P #J R3 #E #J

E1 P1 P1 J2 E1 J2

E1 P2 P2 J1 E1 J1

E2 P1 P1 J1 E2 J1

Suministro  R1  R2, Suministro  R1  R3, Suministro  R2  R3, Suministro = R1  R2  R3

• Quinta forma normal (5FN): Una relación R está en 5FN si y solo si toda DP está implicada por las claves candidatas
de R.
En la realidad no es común tener DP y es muy difícil darse cuenta de su existencia, por lo que Fagin en [Fag-79]
presenta un algoritmo para probar si una DP está implicada por un conjunto de claves en R.

Unidad VII.- Modelo Lógico y Físico.

Introducción
• Al diseñar una BD relacional, podemos obtener diferentes esquemas
• La teoría de la normalización consigue una formalización en el diseño lógico
• ¿Qué propiedades debe tener un esquema para representar adecuadamente la realidad y qué problemas se pueden derivar de
un diseño inadecuado?
• La teoría de la normalización permite afrontar el problema de diseño de bases de datos relacionales de una manera rigurosa y
objetiva
Definiciones Generales.
Modelo relacional
El modelo relacional tiene tres partes principales, que tienen que ver con la estructura de datos, la integridad de los datos y la
manipulación de datos. Cada una de las partes que nombramos anteriormente tiene su propia terminología especial.
En el caso de la estructura de datos, los términos estructurales más importantes son las relaciones. Una relación se encuentra
compuesta por un conjunto de tuplas (cuerpo de la relación) y un conjunto de pares atributo–dominio (cabecera de la relación) y
podría llegar a ser representada físicamente por una tabla. Además cada relación posee su clave primaria, una cardinalidad y un
grado asociado a ella.
La cardinalidad de una relación se encuentra dada por el número de tuplas que contiene la relación (en el caso de que se
represente la relación como una tabla, entonces una tupla es el equivalente a una fila de la tabla). La máxima cardinalidad posible
para una relación es el producto cartesiano de todos los dominios que componen la cabecera de la relación.
El grado es el número de atributos que contiene una relación (en el caso de que nuevamente consideremos a la relación como una
tabla, el grado sería el número de columnas de la misma).
Un dominio es un conjunto de valores atómicos que nos define el conjunto de valores válidos para un atributo.
Modelo entidad-relación
Este es un modelo conceptual de datos de alto nivel muy utilizado introducido por Peter Chen en 1976, que sirve para la
representación de estructuras de información, no conteniendo un lenguaje para representación de manipulaciones de datos
Este modelo y sus variaciones se emplean a menudo en el diseño conceptual de aplicaciones de bases de datos. El objetivo
principal del diseño conceptual es crear un esquema conceptual de alto nivel, independiente del DBMS (Data Base Managment
System), partiendo de especificaciones de requerimientos que describan la realidad.
Al igual que otros problemas en la informática, dada la complejidad que se presenta en el diseño de una base de datos, éste se
divide en sub problemas o etapas independientes que se pueden resolver por separado usando métodos y técnicas específicas. El
diseño de base de datos se divide en tres grandes fases de diseño, con una fase posterior a estas de recolección y análisis de
requerimientos.
Diseño conceptual.
Una vez recabados y analizados todos los requerimientos, el siguiente paso es crear un esquema conceptual para la base de
datos. Éste es una descripción concisa de los requerimientos de información de los usuarios, y contiene descripciones detalladas
de los tipos de datos, las relaciones y las restricciones.
Diseño Lógico.
Esta fase consiste en implementar una descripción de la estructura de la base de datos que puede procesar el software de
DBMS, esto es conocido como esquema lógico.
Diseño Físico.
Este es paso final durante el cual se especifican las estructuras de almacenamiento internas y la organización de los archivos de
la base de datos. Hay una retroalimentación entre el diseño físico y el lógico, porque las decisiones tomadas durante el diseño
físico para mejorar el rendimiento pueden afectar las estructuras del esquema lógico.
Una vez completo el diseño físico de la base de datos, los diseños lógico y físico se expresan mediante un lenguaje de definición
de datos (DDL) del DBMS a usar. De esta forma la base de datos puede ser cargada y probada, y más aún, las aplicaciones que
usan la base de datos se pueden diseñar y probar completamente.
El modelo ER describe los datos como entidades, relaciones y atributos. Una entidad se puede definir como un elemento del
mundo real con existencia independiente. Los atributos son propiedades específicas que describen las entidades. Por último
podemos definir las relaciones como conjunto de asociaciones entre entidades.
Junto con el modelo Entidad-Relación, Chen también presentó el concepto de Diagrama de Entidad–Relación (DER). Los
Diagramas Entidad–Relación constituyen una técnica para representar la estructura lógica de una base de datos en forma de
gráficos. Éstos proporcionan un medio sencillo y de fácil comprensión para comunicar las características sobresalientes de
cualquier base de datos dada. A continuación se presentarán algunos conceptos básicos para elaborar un DER (de todas formas,
los DER pueden ser representados de diversas maneras).
Objetivos de Diseñar una Base de Datos:
Desarrollar buenos esquemas de relación.
Dado cierto conjunto de datos representados en una base de datos
¿Cómo decidimos una estructura lógica conveniente para esos datos?
¿Cómo decidimos que relaciones deben existir y qué atributos deben tener?
Pautas para el Modelamiento y Diseño de BD
• Semántica de los atributos
• Reducción de los valores redundantes en las tuplas
• Reducción de los valores nulos en las tuplas
• Eliminación de la posibilidad de generación de tuplas espurias
Semántica de los atributos
• Pauta 1. Diseñe un esquema de relación que sea fácil de explicar su significado. No combine atributos de varios tipos de
entidad ni tipos de relación en una única relación
Reducción de los valores redundantes en las tuplas
• Pauta 2. Diseñe los esquemas de las relaciones de base de modo que no haya anomalías de inserción, eliminación o modificación
de las relaciones.
Reducción de los valores nulos en las tuplas
• Pauta 3. Hasta donde sea posible, evite incluir en una relación base atributos cuyos valores puedan ser nulos.
Eliminación de la posibilidad de generación de tuplas espurias
• Pauta 4. Diseñe los esquemas de relación de modo que puedan reunirse mediante condiciones de igualdad sobre atributos que
sean llaves primarias o llaves foráneas a fin de garantizar que no se formaran tuplas espurias.
Peligro en el diseño de bases de datos relacionales
• El diseño de bases de datos relacionales requiere que nosotros encontremos un buena colección de esquemas relaciónales. Un
mal diseño nos conduciría a:
• Repetición de información.
• Incapacidad para representar información con certeza.
• Metas del diseño:
– Evitar redundancia de datos.
– Asegurar que las relaciones entre atributos estén representadas
– Facilitar al verificar las actualizaciones para evitar violaciones de integridad de la base de datos.
Macro Ciclo de Vida
• Análisis de Factibilidad
• Obtención y Análisis de requisitos
• Diseño
• Implementación
• Validación y Prueba de Aceptación
• Despliegue, Operación y Mantenimiento
Micro Ciclo de Vida
• Definición del Sistema
• Diseño de la Base de Datos
• Implementación de la Base de Datos
• Carga o Conversión de los Datos
• Conversión de Aplicaciones
• Prueba de Aplicaciones
• Operación
• Supervisión y Mantenimiento
El Proceso de Diseño de Base de Datos
• Diseñar la estructura lógica y física de una o más bases de datos para atender las
necesidades de información de los usuarios en una organización para un conjunto definido de aplicaciones
Objetivos Diseño de Base de Datos
• Satisfacer los requisitos de contenido de información y las aplicaciones
• Proporcionar una estructuración de la información natural
• Soportar los requisitos de procesamiento y cualesquier objetivo de rendimiento
Las 6 Fases Principales en el Proceso de Diseño de Base de Datos
• Obtención y análisis de requisitos
• Diseño conceptual de la base de datos
• Elección de un SGBD
• Transformación al modelo de datos
• Diseño físico de la base de datos
• Implementación y ajuste del sistema de base de datos
Fase 1: Obtención y Análisis de requisitos
• Conocer y analizar las expectativas
• Identificar las demás partes del SI que van a interactuar son el SBD
• Actividades:
1. Se identifican las áreas de aplicación y los usuarios
2. Se estudia y analizar la documentación
3. Se estudia el entorno de operación actual
4. Con apoyo de cuestionarios conocer las prioridades de los usuario.
Fase 2: Diseño Conceptual de la Base de Datos
Se subdivide en dos fases que trabajan en paralelo:
– Diseño del Esquema Conceptual:
Examina los requisitos de la fase 1 y produce un esquema conceptual
– Diseño de Transacciones y Aplicaciones
Examina las aplicaciones de la BD de la fase 1 y produce especificaciones de alto nivel
2a Diseño del Esquema conceptual
• El diseño conceptual que surge de esta fase debe ser independiente del SGBD:
– Entendimiento de la estructura las relaciones y restricciones
– Debe de tener una descripción estable de la BD
– Entendimiento del esquema conceptual y es necesario un lenguaje de alto nivel más expresivo.
– Debe de ser un vehículo de comunicación entre usuarios, diseñadores y analista
• Enfoques para el diseño conceptual
• Tipos de entidades
• Tipos de relaciones
• Atributos
• Restricciones de cardinalidad
• Existen dos enfoques para el diseño conceptual
– Centralizado - todos los requisitos se combinan
– Integración de vistas – se diseñan esquemas por cada grupo de usuarios en base a los requisitos.
Fase 2b Diseño de Transacciones
• Diseñar las características de las transacciones conocidas de la BD con independencia del SGBD.
• Una técnica es especificar las entradas/salidas y su comportamiento funcional de las transacciones a nivel conceptual.
Fase 3: Elecciones del SGBD
• Factores técnicos, económicos y políticas de organización
• Técnicos: estructura de almacenamiento, caminos de accesos, interfaces de usuario, tipos de lenguaje de consultas de alto
nivel, la disponibilidad de herramientas de desarrollo.
• Económicos: adquisición de software, mantenimiento, adquisición de hardware, costo de creación y conversión de BD,
entrenamiento y operación.
Fase 4: Transformación al modelo de datos
• Transformación independiente del sistema
• Adaptación de los esquemas a un SGBD específico.
Fase 5: Diseño Físico de la Base de Datos
• Tiempo de respuesta
• Aprovechamiento del espacio
• Productividad de las transacciones
Modelar el Siguiente Caso:
1. La cadena de Video-Clubs Glob-Gusters ha decidido, para mejorar su servicio, emplear una base de datos para almacenar la
información referente a las películas que ofrece en alquiler. Esta información es la siguiente:
· Una película se caracteriza por su título, nacionalidad, productora y fecha (p.e., “Quo Vadis”, “Estados Unidos”, “M.G.M.”,
1955).
· En una película pueden participar varios actores (nombre, nacionalidad, sexo) algunos de ellos como actores principales.
· Una película está dirigida por un director (nombre, nacionalidad).
· De cada película se dispone de uno o varios ejemplares diferenciados por un número de ejemplar y caracterizados por su
estado de conservación.
· Un ejemplar se puede encontrar alquilado a algún cliente (DNI, nombre, dirección, teléfono). Se desea almacenar la fecha de
comienzo del alquiler y la de devolución.
· Cada socio puede tener alquilados, en un momento dado, 4 ejemplares como
máximo.
· Un socio tiene que ser avalado por otro socio que responda de él en caso de
tener problemas en el alquiler.
Laboratorio: Usando Herramientas de Modelamiento, implementar en Erwin el diseño preparado en el caso práctico.
Unidad VIII.- Diccionarios de Datos y Tipo de Datos.
Diccionario de Base de Datos
Es el documento que contiene toda la información necesaria y relevante acerca de la estructura y modelo de datos de un
determinado sistema.
Es de suma importancia el contar y actualizar este documento como parte de la bitácora o biblioteca de los sistemas de
información.
Contenido de un Manual de Base de Datos:
El contenido que se brinde es este documento es ciertamente relativo pero por lo menos se debe cumplir con los siguientes
puntos:
• Definiciones de todos los esquemas en la B.D (tablas, indices, reglas de validación, vistas, sinónimos, secuencias,
procedimientos, funciones, etc).
• Esquema físico y lógico del modelo de Base de Datos
• Distribución física de la data, espació asignado y ocupado por el sistema.
• La relación de Usuarios, privilegios y roles en la base de datos.
• Información sobre quienes y cuando se han modificado ó actualizado los esquemas.
• Información general de las bases de datos.

Razones de Uso:
• Para facilitar el análisis del sistema y realizar un rápido y adecuado mantenimiento.
• Para definir, asignar y documentar un solo significado a todos los elementos de la B.D.
• Para especificar características propias de un sistema como componentes, reglas de negocio entre otros.
• Para localizar errores y omisiones en el sistema.
• Es un requisito indispensable en la entrega formal de un sistema.

Ejemplo de un Manual de Base de Datos:

1.- Reglas de Validación.
Reglas de Validación

Nombre Regla
RV_MESE @col BETWEEN 0 and 12
RV_SINO @col IN('S','N')
RV_NUME_RUC @col BETWEEN '00000000000' AND '99999999999'
...
DEFAULTS

Nombre Regla
DF_ANNO datepart(year,getdate())
DF_TIPO_SITU ACT'
DF_SINO_SI S'
...
2.- Tipos de Datos definidos para el sistema.

TIPOS DE DATOS DEFINIDOS PARA EL SISTEMA

Nombre Tipo Dato Opción Nula Regla Default
TD_DT_001 datetime NULL DF_FECH_SIST
 TD_IN_MESE int NULL RV_MESE
TD_NU_016_004 numeric(16,4) NULL
TD_VC_001_OPRC varchar(1) NOT NULL DF_TIPO_SITU
...

3.- Relación de tablas del sistema.

TABLAS DE LA BASE DE DATOS
Nombre Regla
TCFACT_CAMB Factores Cambio
TMEMPR Table de Maestras de Empresa
TTMONE Monedas
TTIMPT Impuestos
TTPAIS Paises
...

4.- Detalle de las tablas del sistema.

DETALLE DE TABLAS DEL SISTEMA

Nombre NombreColumnas Tipo de Dato Descripción de Columna

TCFACT_CAMB CO_MONE TD_VC_003 Código de Moneda
FE_CAMB TD_DT_001 Fecha de Tipo de Cambio
FA_CMPR_OFIC TD_UN_009_004 Factor Compra Oficial
FA_CMPR_MERC TD_UN_009_004 Factor Compra Mercado
FA_VNTA_OFIC TD_UN_009_004 Factor Venta Oficial
FA_VNTA_MERC TD_UN_009_004 Factor Venta Mercado
TMEMPR CO_EMPR TD_VC_002_EMPR Código de Empresa
DE_NOMB TD_VC_020 Nombre de Empresa
DE_DIRE TD_VC_100 Dirección de Empresa
CO_PAIS TD_VC_020 Nombre de Pais
TTMONE CO_MONE TD_VC_003 Codigo de Moneda
DE_MONE TD_VC_050 Descripcion de Moneda
SB_MONE TD_VC_003 Simbolo de Moneda
...

5.- Modelo de Datos.

• Diagrama de la Base de Datos.
• Base de Datos Lógica.
• Base de Datos Física.
6.- Relación de Índices.
7.- Relación de Procedimiento Almacenado y que realizan.
8.- Distribución física de los datos.
Tipos de datos:
En Microsoft® SQL Server™, cada columna, variable local, expresión y parámetro dispone de un tipo de datos relacionado, que
es un atributo que especifica el tipo de datos (integer, character, money, etc) que el objeto puede contener. SQL Server
suministra un conjunto de tipos de datos del sistema que define todos los tipos de datos que pueden utilizarse con SQL Server.
El conjunto de tipos de datos suministrados por el sistema se muestra debajo.
También se pueden utilizar tipos de datos definidos por el usuario, que son en realidad alias de los tipos de datos suministrados
por el sistema. Para obtener más información acerca de los tipos de datos definidos por el usuario, consulte sp_addtype y Crear
tipos de datos definidos por el usuario.
Cuando dos expresiones que disponen de tipos de datos diferentes, intercalaciones, precisión, escala o longitud los combina un
operador:
• El tipo de datos de los valores resultantes viene determinado al aplicar las reglas de precedencia de tipos de datos a
los tipos de datos de las expresiones de entrada. Para obtener más información, consulte Precedencia de tipos de
datos.
 • Si el tipo de datos del resultado es char, varchar, text, nchar, nvarchar o ntext, la intercalación del valor del
resultado viene determinado por las reglas de precedencia de la intercalación. Para obtener más información, consulte
Precedencia de intercalación.
• La precisión, escala y longitud del resultado dependen de la precisión, escala y longitud de las expresiones de entrada.
Para obtener más información, consulte Precisión, escala y longitud.
SQL Server proporciona sinónimos de tipos de datos para la compatibilidad con SQL-92. Para obtener más información,
consulte Tipos de datos sinónimos.
Numéricos exactos
Integers
bigint
Datos enteros (números enteros) comprendidos entre -2^63 (-[Link].854.775.808) y 2^63 -1
([Link].854.775.807).
int
Datos enteros (números enteros) comprendidos entre -2^31 (-[Link]) y 2^31 - 1 ([Link]).
smallint
Datos enteros comprendidos entre -215 (-32.768) y 215 - 1 (32.767).
tinyint
Datos enteros comprendidos 0 y 255.
bit
bit
Datos enteros con valor 1 ó 0.
Decimal y numeric
decimal
Datos de precisión y escala numérica fijas comprendidos entre -1038 +1 y 1038 – 1.
numeric
Funcionalmente equivalente a decimal.
money y smallmoney
money
Valores de moneda comprendidos entre -263 (-[Link].477,5808) y 263 - 1 (+[Link].477,5807), con una
precisión de una diezmilésima de la unidad monetaria.
smallmoney
Valores de moneda comprendidos entre -214.748,3648 y +214.748,3647, con una precisión de una diezmilésima de la unidad
monetaria.
Numéricos con aproximación
float
Números con precisión de coma flotante con los siguientes valores válidos: de -1,79E + 308 a -2,23E - 308, 0 y de 2,23E + 308 a
1,79E + 308.
real
Números con precisión de coma flotante con los siguientes valores válidos: de -3,40E + 38 a -1,18E - 38, 0 y de 1,18E - 38 a
3,40E + 38.
datetime y smalldatetime
datetime
Datos de fecha y hora comprendidos entre el 1 de enero de 1753 y el 31 de diciembre de 9999, con una precisión de 3,33
milisegundos.
smalldatetime
Datos de fecha y hora comprendidos entre el 1 de enero de 1900 y el 6 de junio de 2079, con una precisión de un minuto.
Cadenas de caracteres
char
Datos de caracteres no Unicode de longitud fija con una longitud máxima de 8.000 caracteres.
varchar
Datos no Unicode de longitud variable con un máximo de 8.000 caracteres.
text
Datos no Unicode de longitud variable con una longitud máxima de 231 - 1 ([Link]) caracteres.
Cadenas de caracteres Unicode
nchar
Datos Unicode de longitud variable con una longitud máxima de 4.000 caracteres.
nvarchar
Datos Unicode de longitud variable con una longitud máxima de 4.000 caracteres. sysname es el tipo de datos suministrado por
el sistema y definido por el usuario que es funcionalmente equivalente a nvarchar(128) y que se utiliza para hacer referencia a
nombres de objetos de bases de datos.
ntext
Datos Unicode de longitud variable con una longitud máxima de 230 - 1 ([Link]) caracteres.
Cadenas binarias
binary
Datos binarios de longitud fija con una longitud máxima de 8.000 bytes.
varbinary
Datos binarios de longitud variable con una longitud máxima de 8.000 bytes.
image
Datos binarios de longitud variable con una longitud máxima de 231 - 1 ([Link]) bytes.

¿Qué es Unicode?

Básicamente Unicode proporciona un número único para cada carácter, sin importar la plataforma, ni el programa, ni el idioma,
permitiendo un fácil traspaso entre distintos sistemas de codificación y plataformas.

Las computadoras sólo trabajan con números. Almacenan letras y otros caracteres mediante la asignación de un número a cada
uno. Antes de que se inventara Unicode, existían cientos de sistemas de codificación distintos para asignar estos números.
Ninguna codificación específica podía contener caracteres suficientes: por ejemplo, la Unión Europea, por sí sola, necesita
varios sistemas de codificación distintos para cubrir todos sus idiomas. Incluso para un solo idioma como el inglés, no había un
único sistema de codificación que se adecuara a todas las letras, signos de puntuación y símbolos técnicos de uso común.
Además, estos sistemas de codificación presentan problemas entre ellos. Es decir, dos sistemas de codificación pueden utilizar
el mismo número para dos caracteres distintos o bien utilizar números distintos para el mismo carácter. Toda computadora
(especialmente los servidores) necesita ser compatible con muchos sistemas de codificación distintos; sin embargo, cada vez
que los datos se traspasan entre distintos sistemas de codificación o plataformas, dichos datos siempre corren el riesgo de
sufrir daños.
Unicode proporciona un número único para cada carácter, sin importar la plataforma, ni el programa, ni el idioma.
Para ello, este método utiliza dos bytes por cada carácter. Cómo referencia, en el formato ASCII clásico es suficiente un solo
byte para representar cada carácter. Esta mayor cantidad de espacio, normalmente está prevista por los programas y sistemas
operativos que soportan esta codificación, y no debería representar un problema en circunstancias normales.

Tipos de datos definidos por el usuario

sp_addtype

Nueva información: septiembre de 2001.

Crea un tipo de datos definido por el usuario.
Sintaxis
sp_addtype [ @typename = ] type,
[ @phystype = ] system_data_type
[ , [ @nulltype = ] 'null_type' ]
[ , [ @owner = ] 'owner_name' ]
Argumentos
[@typename =] type
Es el nombre del tipo de datos definido por el usuario. Los nombres de los tipos de datos tienen que seguir las reglas de los
identificadores y deben ser únicos en cada base de datos. El argumento type es del tipo de datos sysname y no tiene valor
predeterminado.
[@phystype =] system_data_type
Es el tipo de datos físico, o proporcionado por Microsoft® SQL Server™, (decimal, int, etc.) en el que se basa el tipo de datos
definido por el usuario. El argumento system_data_type es de tipo sysname, no tiene valor predeterminado y puede ser uno de
estos valores:
'binary( n )' int smallint

bit 'nchar( n )' text

'char( n )' ntext tinyint

datetime numeric uniqueidentifier

decimal 'numeric[ ( p [ , s ] ) ]' 'varbinary( n )'

'decimal[ ( p [, s ] ) ]' 'nvarchar( n )' 'varchar( n )'

 float real

image smalldatetime

Se requieren comillas para delimitar los parámetros que tengan espacios o signos de puntuación incrustados. Para obtener más
información acerca de los tipos de datos disponibles, consulte Tipos de datos.
n Es un entero no negativo que indica la longitud del tipo de datos elegido.

p Es un entero no negativo que indica el número total máximo de cifras decimales que se pueden almacenar, a ambos
lados del separador decimal. Para obtener más información, consulte decimal y numeric.

s Es un entero no negativo que indica el número máximo de cifras decimales que se pueden almacenar a la derecha del
separador decimal, y tiene que ser menor que la precisión decimal o igual a esta. Para obtener más información, consulte
"decimal y numeric" en este volumen.
[@nulltype =] 'null_type'
Indica la forma en que el tipo de datos definido por el usuario trata los valores nulos. El argumento null_type es de tipo
varchar(8), su valor predeterminado es NULL y tiene que estar entre comillas simples ('NULL', 'NOT NULL' o 'NONULL'). Si
no se define explícitamente null_type en sp_addtype, se establece según el criterio predeterminado actual para valores nulos.
Utilice la función del sistema GETANSINULL para determinar el criterio predeterminado actual para los valores nulos, que se
puede ajustar mediante la instrucción SET o sp_dboption. El criterio para los valores nulos se tiene que definir explícitamente.

Nota El parámetro null_type sólo define el criterio predeterminado para los valores nulos de este tipo de datos. Si se define
explícitamente un criterio para los valores nulos cuando se utiliza este tipo de datos definido por el usuario durante la creación
de una tabla, este criterio tendrá precedencia sobre el criterio para valores nulos definido. Para obtener más información,
consulte ALTER TABLE y CREATE TABLE.
[@owner =] 'owner_name'
Especifica el propietario o el creador del nuevo tipo de datos. El argumento owner_name es de tipo sysname. Cuando no se
especifica, owner_name es el usuario actual.
Valores del código de retorno
0 (correcto) o 1 (error)
Conjuntos de resultados
Ninguna
Observaciones
Los nombres de los tipos de datos definidos por el usuario tienen que ser únicos en la base de datos, pero tipos de datos
definidos por el usuario con distintos nombres pueden tener la misma definición.
Al ejecutar sp_addtype se crea un tipo de datos definido por el usuario que se agrega a la tabla del sistema systypes de una
base de datos concreta, a menos que sp_addtype se ejecute con master como la base de datos actual. Si el tipo de datos
definido por el usuario tiene que estar disponible en todas las nuevas bases de datos definidas por el usuario, agréguelo a model.
Después de crear un tipo de datos definido por el usuario, puede utilizarse en CREATE TABLE o ALTER TABLE, así como
enlazarse a valores predeterminados y reglas.
No se pueden definir tipos de datos definidos por el usuario que utilicen los tipos de datos timestamp o table de SQL Server.
Permisos
De forma predeterminada, los permisos de ejecución corresponden a la función public.
Ejemplos
A. Crear un tipo de datos definido por el usuario que no admita valores NULL
Este ejemplo crea un tipo de datos definido por el usuario denominado ssn (número de la seguridad social) que está basado en el
tipo de datos varchar de SQL Server. El tipo de datos ssn se utiliza en columnas que almacenan números de la seguridad social
de 11 cifras (999-99-9999). La columna no puede ser NULL.
Observe que varchar(11) está entre comillas simples porque contiene signos de puntuación (paréntesis).
USE master
EXEC sp_addtype ssn, 'VARCHAR(11)', 'NOT NULL'
B. Crear un tipo de datos definido por el usuario que admita valores NULL
Este ejemplo crea un tipo de datos definido por el usuario (basado en el tipo de datos datetime) denominado birthday que
permite valores NULL.
USE master
EXEC sp_addtype birthday, datetime, 'NULL'
C. Crear tipos de datos definidos por el usuario adicionales
Este ejemplo crea dos tipos de datos definidos por el usuario adicionales, telephone y fax, para números de teléfono y fax
locales e internacionales.
USE master
EXEC sp_addtype telephone, 'varchar(24)', 'NOT NULL'
EXEC sp_addtype fax, 'varchar(24)', 'NULL'

PDRMSs usa el Lenguage Estructurado de Busqueda Structured Query Language (SQL, ahora SQL2) como el Data Definition
Language) ( Definicion de lenguage de datos) (DLL) y el Data Manipulation Language(DML).

CREATE TABLE
[ database_name.[ owner ] . | owner. ] table_name
( { < column_definition >
| column_name AS computed_column_expression
| < table_constraint > ::= [ CONSTRAINT constraint_name ] }
| [ { PRIMARY KEY | UNIQUE } [ ,...n ]
)

[ ON { filegroup | DEFAULT } ]
[ TEXTIMAGE_ON { filegroup | DEFAULT } ]

< column_definition > ::= { column_name data_type }

[ COLLATE < collation_name > ]
[ [ DEFAULT constant_expression ]
| [ IDENTITY [ ( seed , increment ) [ NOT FOR REPLICATION ] ] ]
]
[ ROWGUIDCOL]
[ < column_constraint > ] [ ...n ]

< column_constraint > ::= [ CONSTRAINT constraint_name ]

{ [ NULL | NOT NULL ]
| [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
[WITH FILLFACTOR = fillfactor]
[ON {filegroup | DEFAULT} ] ]
]
| [ [ FOREIGN KEY ]
REFERENCES ref_table [ ( ref_column ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ]
]
| CHECK [ NOT FOR REPLICATION ]
( logical_expression )
}
< table_constraint > ::= [ CONSTRAINT constraint_name ]
{ [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
{ ( column [ ASC | DESC ] [ ,...n ] ) }
[WITH FILLFACTOR = fillfactor]
[ ON { filegroup | DEFAULT } ]
]
| FOREIGN KEY
[ ( column [ ,...n ] ) ]
REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ]
| CHECK [ NOT FOR REPLICATION ]
( search_conditions )
}

Ejemplos
A. Utilizar restricciones PRIMARY KEY
El ejemplo siguiente muestra la definición de columna de una restricción PRIMARY KEY con un índice agrupado sobre la columna
job_id de la tabla jobs (que permite al sistema suministrar el nombre de la restricción) en la base de datos de ejemplo pubs.
job_id smallint
PRIMARY KEY CLUSTERED
Este ejemplo muestra cómo se puede suministrar un nombre para la restricción PRIMARY KEY. Esta restricción se utiliza en la
columna emp_id de la tabla employee. Esta columna se basa en un tipo de datos definido por el usuario.
emp_id empid
CONSTRAINT PK_emp_id PRIMARY KEY NONCLUSTERED
B. Utilizar restricciones FOREIGN KEY
Una restricción FOREIGN KEY se utiliza para hacer referencia a otra tabla. Las claves externas pueden ser claves de una única
columna o de varias columnas. El ejemplo siguiente muestra una restricción FOREIGN KEY de una única columna sobre la tabla
employee que hace referencia a la tabla jobs. Sólo se requiere la cláusula REFERENCES para una restricción FOREIGN KEY de
una única columna.
job_id smallint NOT NULL
DEFAULT 1
REFERENCES jobs(job_id)
También puede utilizar la cláusula FOREIGN KEY de forma explícita y volver a formular el atributo de columna. Observe que no
es necesario que el nombre de la columna sea el mismo en ambas tablas.
FOREIGN KEY (job_id) REFERENCES jobs(job_id)
Las restricciones de claves de varias columnas se crean como restricciones de tabla. En la base de datos pubs, la tabla sales
incluye una restricción PRIMARY KEY multicolumna. Este ejemplo muestra cómo hacer referencia a esta clave desde otra tabla;
el nombre explícito de restricción es opcional.
CONSTRAINT FK_sales_backorder FOREIGN KEY (stor_id, ord_num, title_id)
REFERENCES sales (stor_id, ord_num, title_id)
C. Utilizar restricciones UNIQUE
Las restricciones UNIQUE se utilizan para exigir la unicidad en las columnas de claves no principales. Una columna de
restricción PRIMARY KEY incluye automáticamente una restricción de unicidad; sin embargo, una restricción UNIQUE puede
aceptar valores NULL. Este ejemplo muestra una columna llamada pseudonym de la tabla authors. Exige la restricción de que los
pseudónimos de los autores sean únicos.
pseudonym varchar(30) NULL
UNIQUE NONCLUSTERED
El ejemplo siguiente muestra una restricción UNIQUE creada en las columnas stor_name y city de la tabla stores, donde
stor_id es actualmente la restricción PRIMARY KEY; no debe haber dos almacenes iguales en la misma ciudad.
CONSTRAINT U_store UNIQUE NONCLUSTERED (stor_name, city)
D Utilizar definiciones DEFAULT
Los valores predeterminados suministran un valor (con las instrucciones INSERT y UPDATE) cuando no se especifica ninguno. En
la base de datos pubs, se utilizan muchas definiciones DEFAULT para asegurar que se introducen los datos y marcadores de
posición adecuados.
En la tabla jobs, una cadena de caracteres predeterminada suministra una descripción (columna job_desc) cuando la descripción
actual no se introduce explícitamente.
DEFAULT 'New Position - title not formalized yet'
En la tabla employee, los empleados pueden trabajar para una imprenta o para la compañía primaria. Cuando no se suministra una
compañía de forma explícita, se introduce la compañía primaria (observe que, como se muestra aquí, se pueden anidar
comentarios en la definición de la tabla).
DEFAULT ('9952')
/* By default the Parent Company Publisher is the company
to whom each employee reports. */
Además de constantes, las definiciones de DEFAULT pueden incluir funciones. Utilice este ejemplo para obtener la fecha actual
de una entrada:
DEFAULT (getdate())
Las funciones niládicas pueden mejorar también la integridad de los datos. Para realizar el seguimiento del usuario que insertó
una fila, utilice la función niládica para USER (no escriba las funciones niládicas entre paréntesis):
DEFAULT USER
E. Utilizar restricciones CHECK
Este ejemplo muestra las restricciones realizadas a los valores introducidos en las columnas min_lvl y max_lvl de la tabla jobs.
Estas dos restricciones no tienen nombre:
CHECK (min_lvl >= 10)
y
CHECK (max_lvl <= 250)
Este ejemplo muestra una restricción con nombre con una restricción de patrón sobre los datos de caracteres introducidos en
la columna emp_id de la tabla employee.
CONSTRAINT CK_emp_id CHECK (emp_id LIKE
'[A-Z][A-Z][A-Z][1-9][0-9][0-9][0-9][0-9][FM]' OR
emp_id LIKE '[A-Z]-[A-Z][1-9][0-9][0-9][0-9][0-9][FM]')
Este ejemplo especifica que pub_id debe estar en una lista específica o seguir un modelo dado. Esta restricción afecta a la
columna pub_id de la tabla publishers.
CHECK (pub_id IN ('1389', '0736', '0877', '1622', '1756')
OR pub_id LIKE '99[0-9][0-9]')
F. Definiciones de tablas completas
El ejemplo siguiente muestra definiciones completas de tablas con las definiciones de restricciones de tres tablas (jobs,
employee y publishers) creadas en la base de datos pubs.
/* ************************** jobs table ************************** */
CREATE TABLE jobs
(
job_id smallint
IDENTITY(1,1)
PRIMARY KEY CLUSTERED,
job_desc varchar(50) NOT NULL
DEFAULT 'New Position - title not formalized yet',
min_lvl tinyint NOT NULL
CHECK (min_lvl >= 10),
max_lvl tinyint NOT NULL
CHECK (max_lvl <= 250)
)

/* ************************* employee table ************************* */

CREATE TABLE employee
(
emp_id empid
CONSTRAINT PK_emp_id PRIMARY KEY NONCLUSTERED
CONSTRAINT CK_emp_id CHECK (emp_id LIKE
'[A-Z][A-Z][A-Z][1-9][0-9][0-9][0-9][0-9][FM]' or
emp_id LIKE '[A-Z]-[A-Z][1-9][0-9][0-9][0-9][0-9][FM]'),
/* Each employee ID consists of three characters that
represent the employee's initials, followed by a five
digit number ranging from 10000 through 99999 and then the
employee's gender (M or F). A (hyphen) - is acceptable
for the middle initial. */
fname varchar(20) NOT NULL,
minit char(1) NULL,
lname varchar(30) NOT NULL,
job_id smallint NOT NULL
DEFAULT 1
/* Entry job_id for new hires. */
REFERENCES jobs(job_id),
job_lvl tinyint
DEFAULT 10,
/* Entry job_lvl for new hires. */
pub_id char(4) NOT NULL
DEFAULT ('9952')
REFERENCES publishers(pub_id),
/* By default, the Parent Company Publisher is the company
to whom each employee reports. */
hire_date datetime NOT NULL
DEFAULT (getdate())
/* By default, the current system date is entered. */
)

/* ***************** publishers table ******************** */

CREATE TABLE publishers
(
pub_id char(4) NOT NULL
 CONSTRAINT UPKCL_pubind PRIMARY KEY CLUSTERED
CHECK (pub_id IN ('1389', '0736', '0877', '1622', '1756')
OR pub_id LIKE '99[0-9][0-9]'),
pub_name varchar(40) NULL,
city varchar(20) NULL,
state char(2) NULL,
country varchar(30) NULL
DEFAULT('USA')
)
G. Utilizar una expresión para una columna calculada
Este ejemplo ilustra el uso de una expresión ((low + high)/2) para calcular la columna calculada myavg.
CREATE TABLE mytable
(
low int,
high int,
myavg AS (low + high)/2
)

Permiso a tablas

Grant all on extra to public

GRANT
Crea una entrada en el sistema de seguridad que permite a un usuario de la base de datos actual trabajar con datos de la base
de datos actual o ejecutar instrucciones Transact-SQL específicas.
Sintaxis
Permisos de la instrucción:
GRANT { ALL | statement [ ,...n ] }
TO security_account [ ,...n ]
Permisos del objeto:
GRANT
{ ALL [ PRIVILEGES ] | permission [ ,...n ] }
{
[ ( column [ ,...n ] ) ] ON { table | view }
| ON { table | view } [ ( column [ ,...n ] ) ]
| ON { stored_procedure | extended_procedure }
| ON { user_defined_function }
}
TO security_account [ ,...n ]
[ WITH GRANT OPTION ]
[ AS { group | role } ]
PRIVILEGES
Es una palabra clave opcional que se puede incluir para cumplir con SQL-92.
permission
Se trata de un permiso de objeto que se concede. Cuando se conceden permisos sobre una tabla, una función de valores de tabla
o una vista, la lista de permisos puede incluir uno o más de los siguientes permisos: SELECT, INSERT, DELETE, REFERENCES o
UPDATE. Es posible suministrar una lista de columnas junto con los permisos SELECT y UPDATE. Si no se suministra una lista de
columnas con los permisos SELECT y UPDATE, los permisos se aplican a todas las columnas de la tabla, vista o función de valores
de tabla.
Los permisos que se conceden a objetos en un procedimiento almacenado sólo pueden incluir EXECUTE. Los permisos que se
conceden a objetos en una función de valores escalares pueden incluir EXECUTE y REFERENCES.
Para tener acceso a una columna en una instrucción SELECT es necesario disponer de permiso para utilizar SELECT en esa
columna. Para actualizar una columna mediante una instrucción UPDATE es necesario disponer de permiso para utilizar UPDATE
en esa columna.
Para crear una restricción FOREIGN KEY que haga referencia a una tabla es necesario disponer de permiso para utilizar
REFERENCES en esa tabla.
Para crear una FUNCTION o VIEW con la cláusula WITH SCHEMABINDING que haga referencia a un objeto es necesario
disponer de permiso para utilizar REFERENCES en ese objeto.
column
Es el nombre de la columna de la base de datos actual sobre la que se conceden los permisos.
table
Es el nombre de la tabla de la base de datos actual sobre la que se conceden los permisos.
view
Es el nombre de la vista de la base de datos actual sobre la que se conceden los permisos.
stored_procedure
Es el nombre del procedimiento almacenado de la base de datos actual sobre el que se conceden los permisos.
extended_procedure
Es el nombre del procedimiento almacenado extendido sobre el que se conceden los permisos.
user_defined_function
Es el nombre de la función definida por el usuario sobre la que se conceden los permisos.
WITH GRANT OPTION
Especifica que se concede a security_account la capacidad de conceder el permiso de objeto especificado a otras cuentas de
seguridad. La cláusula WITH GRANT OPTION sólo es válida con los permisos de objeto.
AS {group | role}
Especifica el nombre opcional de la cuenta de seguridad de la base de datos actual que tiene los permisos necesarios para
ejecutar la instrucción GRANT. AS se utiliza cuando se conceden permisos sobre un objeto a un grupo o función, y es necesario
que los permisos de objetos se concedan además a otros usuarios que no son miembros del grupo o función. Debido a que sólo un
usuario, y no un grupo o función, puede ejecutar una instrucción GRANT, un miembro específico del grupo o función concederá
los permisos del objeto bajo la autoridad del grupo o función.
Observaciones
Los permisos entre bases de datos diferentes no están permitidos. Sólo se deben conceder permisos a los usuarios de la base
de datos actual y sobre objetos e instrucciones de la base de datos actual. Si un usuario necesita permisos para objetos de otra
base de datos, cree la cuenta del usuario en la otra base de datos o conceda a la cuenta del usuario acceso a la otra base de
datos y a la base de datos actual.

Nota Los procedimientos almacenados en el sistema son la excepción ya que los permisos EXECUTE ya están concedidos a la
función public, lo que permite a cualquiera ejecutarlos. Sin embargo, después de su ejecución, los procedimientos almacenados
del sistema comprueban la pertenencia del usuario a la función. Si el usuario no es miembro de la función fija de servidor o de
base de datos que corresponda para ejecutar el procedimiento almacenado, éste no continuará.
Se puede utilizar la instrucción REVOKE para retirar permisos concedidos y la instrucción DENY para evitar que un usuario
obtenga permisos mediante la instrucción GRANT referida a su cuenta de usuario.
Un permiso concedido quita los permisos denegados o revocados en el nivel en el que se concede (usuario, grupo o función). Sin
embargo, la denegación del mismo permiso en otro nivel, como el de un grupo o función que contenga al usuario, sí prevalece.
Aunque sí se aplica la revocación del mismo permiso en otro nivel, ello no impide al usuario el acceso al objeto.
Si un usuario aplica una función de aplicación, el efecto de GRANT es nulo para los objetos a los que el usuario tenga acceso con
la función de aplicación. Por ello, aunque es posible conceder a un usuario acceso a un objeto específico de la base de datos
actual, si ese usuario utiliza una función de aplicación que no tiene acceso al objeto, él tampoco tendrá acceso mientras esté
activada la función de aplicación.
ALTER TABLE
Modifica una definición de tabla al alterar, agregar o quitar columnas y restricciones, o al deshabilitar o habilitar restricciones
y desencadenadores.
Sintaxis
ALTER TABLE table
{ [ ALTER COLUMN column_name
{ new_data_type [ ( precision [ , scale ] ) ]
[ COLLATE < collation_name > ]
[ NULL | NOT NULL ]
| {ADD | DROP } ROWGUIDCOL }
]
| ADD
{ [ < column_definition > ]
| column_name AS computed_column_expression
} [ ,...n ]
| [ WITH CHECK | WITH NOCHECK ] ADD
{ < table_constraint > } [ ,...n ]
| DROP
{ [ CONSTRAINT ] constraint_name
| COLUMN column } [ ,...n ]
| { CHECK | NOCHECK } CONSTRAINT
{ ALL | constraint_name [ ,...n ] }
| { ENABLE | DISABLE } TRIGGER
{ ALL | trigger_name [ ,...n ] }
}
< column_definition > ::=
{ column_name data_type }
[ [ DEFAULT constant_expression ] [ WITH VALUES ]
| [ IDENTITY [ ( seed , increment ) [ NOT FOR REPLICATION ] ] ]
]
[ ROWGUIDCOL ]
[ COLLATE < collation_name > ]
[ < column_constraint > ] [ ...n ]
< column_constraint > ::=
[ CONSTRAINT constraint_name ]
{ [ NULL | NOT NULL ]
| [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
[WITH FILLFACTOR = fillfactor]
[ ON { filegroup | DEFAULT } ]
]
| [ [ FOREIGN KEY ]
REFERENCES ref_table [ ( ref_column ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ]
]
| CHECK [ NOT FOR REPLICATION ]
( logical_expression )
}
< table_constraint > ::=
[ CONSTRAINT constraint_name ]
{ [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
{ ( column [ ,...n ] ) }
[WITH FILLFACTOR = fillfactor]
[ ON { filegroup | DEFAULT } ]
]
| FOREIGN KEY
[ ( column [ ,...n ] ) ]
REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ]
| DEFAULT constant_expression
[ FOR column ] [ WITH VALUES ]
| CHECK [ NOT FOR REPLICATION ]
( search_conditions )
}

A. Alterar una tabla para agregar una nueva columna

El ejemplo siguiente agrega una columna que permite valores NULL y a la que no se han proporcionado valores mediante una
definición DEFAULT. Cada fila tendrá un valor NULL en la nueva columna.
CREATE TABLE doc_exa ( column_a INT)
GO
ALTER TABLE doc_exa ADD column_b VARCHAR(20) NULL
GO
EXEC sp_help doc_exa
GO
DROP TABLE doc_exa
GO
B. Alterar una tabla para quitar una columna
El ejemplo siguiente modifica una tabla para quitar una columna.
CREATE TABLE doc_exb ( column_a INT, column_b VARCHAR(20) NULL)
GO
ALTER TABLE doc_exb DROP COLUMN column_b
GO
EXEC sp_help doc_exb
GO
DROP TABLE doc_exb
GO
C. Alterar una tabla para agregar una columna con una restricción
El ejemplo siguiente agrega una nueva columna con una restricción UNIQUE.
CREATE TABLE doc_exc ( column_a INT)
GO
ALTER TABLE doc_exc ADD column_b VARCHAR(20) NULL
CONSTRAINT exb_unique UNIQUE
GO
EXEC sp_help doc_exc
GO
DROP TABLE doc_exc
GO
D. Alterar una tabla para agregar una restricción no comprobada
El ejemplo siguiente agrega una restricción a una columna existente de la tabla. La columna tiene un valor que infringe la
restricción; por tanto, se utiliza WITH NOCHECK para impedir que la restricción se valide contra las filas existentes y para
permitir que se agregue la restricción.
CREATE TABLE doc_exd ( column_a INT)
GO
INSERT INTO doc_exd VALUES (-1)
GO
ALTER TABLE doc_exd WITH NOCHECK
ADD CONSTRAINT exd_check CHECK (column_a > 1)
GO
EXEC sp_help doc_exd
GO
DROP TABLE doc_exd
GO
E. Alterar una tabla para agregar varias columnas con restricciones
El ejemplo siguiente agrega varias columnas con restricciones que se definen con la nueva columna. La primera columna nueva
tiene una propiedad IDENTITY; cada fila de la tabla tiene nuevos valores incrementales en la columna de identidad.
CREATE TABLE doc_exe ( column_a INT CONSTRAINT column_a_un UNIQUE)
GO
ALTER TABLE doc_exe ADD

/* Add a PRIMARY KEY identity column. */

column_b INT IDENTITY
CONSTRAINT column_b_pk PRIMARY KEY,

/* Add a column referencing another column in the same table. */

column_c INT NULL
CONSTRAINT column_c_fk
REFERENCES doc_exe(column_a),

/* Add a column with a constraint to enforce that */

/* nonnull data is in a valid phone number format. */
column_d VARCHAR(16) NULL
CONSTRAINT column_d_chk
CHECK
(column_d IS NULL OR
column_d LIKE "[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]" OR
column_d LIKE
"([0-9][0-9][0-9]) [0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]"),

/* Add a nonnull column with a default. */

column_e DECIMAL(3,3)
CONSTRAINT column_e_default
DEFAULT .081
GO
EXEC sp_help doc_exe
GO
DROP TABLE doc_exe
GO
F. Agregar una columna que acepta NULL con valores predeterminados
El ejemplo siguiente agrega una columna que acepta NULL con una definición DEFAULT y utiliza WITH VALUES para
proporcionar los valores de cada fila existente en la tabla. Si no se utiliza WITH VALUES, cada fila tiene el valor NULL en la
nueva columna.
ALTER TABLE MyTable
ADD AddDate smalldatetime NULL
CONSTRAINT AddDateDflt
DEFAULT getdate() WITH VALUES
EJEMPLO:
ALTER TABLE EXCLU ALTER COLUMN RUC VARCHAR(25) NOT NULL

ALTER TABLE EXCLU ADD PRIMARY KEY (RUC)

CREATE TABLE EXCLU2

(RUC VARCHAR(25))

ALTER TABLE EXCLU2 ADD FOREIGN KEY (RUC) REFERENCES EXCLU(RUC)

DROP TABLE
Quita una definición de tabla y todos los datos, índices, desencadenadores, restricciones y especificaciones de permisos de la
tabla. Las vistas o procedimientos almacenados que hagan referencia a la tabla quitada se deben quitar explícitamente con
la instrucción DROP VIEW o DROP PROCEDURE.
Sintaxis
DROP TABLE table_name
Argumentos
table_name
Es el nombre de la tabla que se va a quitar.
Observaciones
No se puede utilizar DROP TABLE para quitar una tabla a la que se haga referencia con una restricción FOREIGN KEY. Primero
se debe quitar la restricción FOREIGN KEY o la tabla de referencia.
El propietario de una tabla puede quitar la tabla de cualquier base de datos. Cuando se quita la tabla, las reglas o valores
predeterminados de la misma pierden sus enlaces y se quitan automáticamente las restricciones o desencadenadores asociados
con ella. Si vuelve a crear una tabla, debe volver a enlazar las reglas y valores predeterminados apropiados, volver a crear los
desencadenadores y agregar todas las restricciones necesarias.
No puede utilizar la instrucción DROP TABLE sobre las tablas del sistema.
Si elimina todas las filas de una tabla (DELETE tablename) o utiliza la instrucción TRUNCATE TABLE, la tabla existe hasta que
se quite.
Permisos
Los permisos para utilizar DROP TABLE pertenecen de manera predeterminada al propietario de la tabla y no se pueden
transferir. Sin embargo, los miembros de la función fija de servidor sysadmin o de las funciones fijas de base de datos
db_owner y db_ddladmin pueden quitar cualquier objeto si especifican el propietario en la instrucción DROP TABLE.
Ejemplos
A. Quitar una tabla de la base de datos actual
Este ejemplo quita la tabla titles1, y sus datos e índices de la base de datos actual.
DROP TABLE titles1
B. Quitar una tabla de otra base de datos
Este ejemplo quita la tabla authors2 de la base de datos pubs. Se puede ejecutar desde cualquier base de datos.
DROP TABLE [Link].authors2

Ing. Marco Sandoval

CIP: 76201
Ejercicios de Modelamiento Lógico
1. La empresa de formación X, desea llevar un control informatizado de los cursos que imparte así como de lo profesores
que participan en dichos cursos. Para ello, nos han dado las siguientes especificaciones:
Cada  curso, del que se desea conocer el título, el número de horas y el tema o los temas que trata, se identifica por un
código de cuso.
Cada
 curso puede tener una serie de cursos cuyo realización previa es obligatoria (prerrequisito) o recomendada.
Cada
 curso se puede impartir una o varias veces, en diferentes fechas y en cada edición del mismo pueden participar
diferentes empleados.
Los  empleados, de los que se desea conocer su código de empleado, nombre, DNI y fecha de antigüedad en la empresa,
pueden impartir y recibir cursos pero con la restricción de que en una mismo edición de un curso no pueden participar
como profesores y como alumnos.

2. La asociación "Amigos de la Fiesta" desea recoger en una base de datos toda la información acerca de las corridas de
toros que se celebran en España y de todos los datos relacionados con ellas.
Se
 desea tener información acerca de cada corrida, identificada conjuntamente por un número de orden, la feria en la
que se celebra y el año de celebración (por ejemplo: orden = 2, feria = San Isidro, año = 1990); las corridas que no se
celebran durante una feria tienen 0 en el campo Feria y se numeran correlativamente dentro de ese año.
En  una determinada corrida actúan una serie de toreros (mínimo 1 y máximo 6) de los que se desea guardar su DNI,
nombre, apodo y fecha en que tomó la alternativa. Además se desea saber quién fue el torero (padrino) que le dio la
alternativa en su día (un torero puede dar la alternativa a varios compañeros o a ninguno).
En  cada corrida un torero obtiene una serie de premios (número de orejas, de rabos y si salió por la puerta grande) de
los que se desea mantener información.
Cada  torero puede tener un apoderado. A su vez, un apoderado lo puede ser de varios toreros. De él se desea saber su
DNI, nombre, dirección y teléfono.
Una  corrida se celebra en una plaza de toros de la que se desea saber su nombre (que se supone único), localidad,
dirección y aforo. En una misma plaza se pueden celebrar varias corridas de toros.
Cada  toro pertenece a una ganadería determinada. De cada ganadería se quiere conocer su código, nombre, localidad,
procedencia y antigüedad (fecha de creación).
En  cada corrida son estoqueados al menos 6 toros. Cada toro viene identificado por el código de la ganadería a la que
pertenece, el año en que nació y un número de orden. Además se desea mantener información acerca de su nombre y
color, así como del orden en que fue toreado.

3. La empresa Personal Quality desea incorporar en su política de contratación criterios de calidad del personal basados
en la medición de sus habilidades o competencias.
La
 empresa desea medir las competencias intelectuales de todos sus empleados y además desea conocer las
competencias emocionales de sus directivos (por ejemplo, la capacidad de trabajo en grupo, la motivación, capacidad de
liderazgo, etc.). De todas ellas se desea conocer: su código de identificación, su nombre y su descripción. Además, para
cada competencia emocional se desea conocer, lo que se ha denominado el umbral; es decir, el valor mínimo de cada
competencia por debajo del cual ningún empleado podrá ser directivo. Se requiere también que todo directivo mantenga
este umbral mínimo en, al menos, 5 competencias emocionales.
Para
 llevar a cabo este estudio, Personal Quality ha contactado con el Emocional Skill Center quien le ha proporcionado
una batería de Test. Cada competencia está asociada a un conjunto de test que permiten medirla. Un test puede medir
una única competencia. Cada test se identifica por un nombre y debe tener asociado un conjunto de preguntas, una
plantilla para su corrección así como el modo en que se deberán interpretar los resultados.
Cada  empleado se identifica por un código interno. Además se quiere conocer el nombre, la dirección y un teléfono de
contacto de cada empleado.

4. La gestión de una farmacia requiere poder llevar control de los medicamentos existentes, así como de los que se van
sirviendo, para lo cual se pretende diseñar un sistema acorde a las siguientes especificaciones:
 la farmacia se requiere una catalogación de todos los medicamentos existentes, para lo cual se almacenará un código
En
de medicamento, nombre del medicamento, tipo de medicamento (jarabe, comprimido, pomada, etc.), unidades en stock,
unidades vendidas y precio. Existen medicamentos de venta libre, y otros que sólo pueden dispensarse con receta médica.
La farmacia adquiere cada medicamento a un laboratorio, o bien los fabrica ella misma. Se desea conocer el código del
laboratorio, nombre, teléfono, dirección, fax así como el nombre de la persona de contacto.
Los medicamentos se agrupan en familias, dependiendo del tipo de enfermedades a las que dicho medicamento se aplica.
La  farmacia tiene algunos clientes que realizan los pagos de sus pedidos a fin de cada mes (clientes con crédito). La
farmacia quiere conocer las unidades de cada medicamento comprado (con o sin crédito) así como la fecha de compra.
Además, es necesario tener los datos bancarios de los clientes con crédito, así como la fecha de pago de las compras que
realizan.

5. Se trata de diseñar una base de datos para una red de agencias franquiciadas a TECHNOHOUSE, empresa
especializada en el alquiler y compra de inmuebles.
 Cada
 agencia tiene un titular propio y un conjunto de vendedores. Tanto el titular como los vendedores sólo pueden
pertenecer a una agencia. Sobre las agencias interesa almacenar su dirección, teléfonos (que pueden ser varios), fax,
etc. Además, cada agencia tiene asignada una zona de actuación que es única.
Las agencias disponen de inmuebles tanto para alquilar como para vender (o ambas cosas), en el primer caso figurará el
precio de alquiler y la fianza a depositar, mientras que en el segundo caso, además del precio de venta, se indica si el
inmueble está o no hipotecado.
Por  otro lado, los inmuebles pueden ser locales comerciales, o pisos. En ambos casos se identifican por un código,
interesando conocer el propietario, la dirección y la superficie en m2.
Además, en el caso de pisos interesa conocer el número de habitaciones (incluyendo el salón), el número de cuartos de
baño, el tipo de gas (natural, ciudad, butano), y si es interior o exterior. Para los locales comerciales se debe conocer si
dispone de licencia de apertura.
Un  cliente puede acudir a varias agencias, en cada una se le asigna un vendedor, que es el encargado de seleccionar los
inmuebles que cumplen las características deseadas, y en caso de estar interesado, el cliente debe dar una señal para
reservar el inmueble (o los inmuebles) que desea.

6. La empresa “X” desea llevar un control de sus departamentos, empleados y proyectos según las siguientes
especificaciones:
Se
 desea conocer el nombre, salario y número de la seguridad social de cada empleado, así como el nombre, fecha de
nacimiento y estudios que cursa, de cada uno de sus hijos. Existen varios tipos de empleados: directores (encargados de
un departamento), representantes de ventas (se ocupan de la representación en un número de regiones) e ingenieros
(encargados de realizar los proyectos de la empresa); hay, además, otros empleados, como secretarios, auxiliares de
laboratorio, etc. Un director no puede ejercer ninguna otra función; sin embargo, un representante de ventas puede
desempeñar también las funciones de un ingeniero y viceversa.
Los distintos departamentos concede becas de estudio a los hijos de los empleados. Estas becas no están tipificadas,
sino que son ayudas que se conceden dependiendo del presupuesto del que disponga el departamento. Se desea conocer la
fecha de concesión de cada beca así como la cuantía de ésta.
Un  ingeniero puede tener varias especialidades que se desean conocer.
De  los departamentos se necesita saber, el nombre, localización y empleados que trabajan en él. Un departamento
tiene, como mínimo 2 empleados y como máximo 30 y está al cargo de un único director. Cada departamento tiene un
director distinto.
Un  departamento puede controlar un número de proyectos, de los que se desea conocer su nombre y fecha de
comienzo.
En  la realización de un proyecto no puede haber involucrados más de 5 ingenieros. Todo ingeniero debe estar asociado a
1 proyecto como mínimo y a 2 como máximo. En el caso de que un departamento no tenga ningún proyecto, sus empleados
podrán estar trabajando en proyectos de otros departamentos.

7. Se trata de diseñar la base de datos para la administración de un consorcio de hospitales, que permita gestionar
datos acerca del personal así como de los pacientes de los mismos. De cada hospital interesa almacenar además de su
nombre dirección, teléfono, fax, etc.
 personal de los hospitales (del que interesa almacenar su DNI, nombre, apellidos, dirección y teléfono) se divide en
El
personal administrativo y personal sanitario (dentro de este se distingue a su vez ATS y médicos).
Los
 médicos tienen una especialidad que interesa conocer (pediatría, obstetricia, etc.) y sólo trabajan, al igual que el
resto del personal, en un hospital.
Los  pacientes pueden acudir a varios hospitales del consorcio, pudiendo ser atendidos por varios médicos.
Se  desea conocer los datos personales de los pacientes que van a ingresar en el hospital, así como el número de
seguridad social, compañía aseguradora, la fecha de admisión y la sala (habitación) en la que deben permanecer.
Cada  sala se identifica por un número de sala dentro de cada hospital y se desea conocer el número de camas de las que
dispone cada sala.
Cada  admisión de un paciente en el hospital lleva asociada una o varias fichas de tratamiento en las que se indica la
enfermedad y el médico que la atiende. Cada tratamiento se identifica por el nombre de la enfermedad del tratamiento
que es único para cada admisión.
Además,  cada tratamiento da lugar a distintos resultados que permiten realizar el seguimiento de cada enfermedad de
un paciente. El resultado debe indicar la fecha y hora en que éste tuvo lugar, así como un comentario (por ejemplo,
indicando si el paciente tiene fiebre etc.). Para un mismo tratamiento sólo puede haber un resultado en un mismo día, a
una misma hora.

Componentes de un sistema de gestión de bases de datos

Los SGBD son paquetes de software muy complejos y sofisticados que deben proporcionar los servicios comentados en la
sección anterior. No se puede generalizar sobre los elementos que componen un SGBD ya que varían mucho unos de otros. Sin
embargo, es muy útil conocer sus componentes y cómo se relacionan cuando se trata de comprender lo que es un sistema de
bases de datos.
Un SGBD tiene varios módulos, cada uno de los cuales realiza una función específica. El sistema operativo proporciona servicios
básicos al SGBD, que es construido sobre él.
• El procesador de consultas es el componente principal de un SGBD. Transforma las consultas en un conjunto de
instrucciones de bajo nivel que se dirigen al gestor de la base de datos.
• El gestor de la base de datos es el interface con los programas de aplicación y las consultas de los usuarios. El gestor
de la base de datos acepta consultas y examina los esquemas externo y conceptual para determinar qué registros se
requieren para satisfacer la petición. Entonces el gestor de la base de datos realiza una llamada al gestor de ficheros
para ejecutar la petición.
• El gestor de ficheros maneja los ficheros en disco en donde se almacena la base de datos. Este gestor establece y
mantiene la lista de estructuras e índices definidos en el esquema interno. Si se utilizan ficheros dispersos, llama a la
función de dispersión para generar la dirección de los registros. Pero el gestor de ficheros no realiza directamente la
entrada y salida de datos. Lo que hace es pasar la petición a los métodos de acceso del sistema operativo que se
encargan de leer o escribir los datos en el buffer del sistema.
• El preprocesador del LMD convierte las sentencias del LMD embebidas en los programas de aplicación, en llamadas a
funciones estándar escritas en el lenguaje anfitrión. El preprocesador del LMD debe trabajar con el procesador de
consultas para generar el código apropiado.
• El compilador del LDD convierte las sentencias del LDD en un conjunto de tablas que contienen metadatos. Estas
tablas se almacenan en el diccionario de datos.
• El gestor del diccionario controla los accesos al diccionario de datos y se encarga de mantenerlo. La mayoría de los
componentes del SGBD acceden al diccionario de datos.
Los principales componentes del gestor de la base de datos son los siguientes:
• Control de autorización. Este módulo comprueba que el usuario tiene los permisos necesarios para llevar a cabo la
operación que solicita.
• Procesador de comandos. Una vez que el sistema ha comprobado los permisos del usuario, se pasa el control al
procesador de comandos.
• Control de la integridad. Cuando una operación cambia los datos de la base de datos, este módulo debe comprobar que
la operación a realizar satisface todas las restricciones de integridad necesarias.
• Optimizador de consultas. Este módulo determina la estrategia óptima para la ejecución de las consultas.
• Gestor de transacciones. Este módulo realiza el procesamiento de las transacciones.
• Planificador (scheduler). Este módulo es el responsable de asegurar que las operaciones que se realizan
concurrentemente sobre la base de datos tienen lugar sin conflictos.
• Gestor de recuperación. Este módulo garantiza que la base de datos permanece en un estado consistente en caso de
que se produzca algún fallo.
• Gestor de buffers. Este módulo es el responsable de transferir los datos entre memoria principal y los dispositivos de
almacenamiento secundario. A este módulo también se le denomina gestor de datos.