Fundamentos de BasedeDatos

Fundamentos de Bases de Datos
Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
www.sceu.frba.utn.edu.ar/e-learning
p. 2
Modelo de Datos

p. 3
Presentación:
A continuación, aprenderemos a diseñar una base de datos desde su inicio, utilizando la
técnica de Diagrama de Entidad relación, que permitirá ser el paso previo a la
construcción de una base de datos Física.

p. 4
Objetivos:
Que los participantes*:
• Comprendan como diseñar un modelo de base de datos del negocio.
• Conozcan la historia de las bases de datos.
• Conozcan distintos tipos de las bases de datos.
• Conozcan las distintas marcas de las bases de datos que hay en el mercado.
• Observen diferencias entre modelo lógico y físico.
• Aprendan el concepto de integridad referencial.
• Instalen una base de datos desde cero con el motor de MySQL.

p. 5
Consignas para el aprendizaje colaborativo
En esta Unidad los participantes se encontrarán con diferentes tipos de actividades que, en
el marco de los fundamentos del MEC*, los referenciarán a tres comunidades de
aprendizaje, que pondremos en funcionamiento en esta instancia de formación, a los
efectos de aprovecharlas pedagógicamente:
● Los foros proactivos asociados a cada una de las unidades.

● La Web 2.0.
● Los contextos de desempeño de los participantes.
Es importante que todos los participantes realicen algunas de las actividades sugeridas y
compartan en los foros los resultados obtenidos.
Además, también se propondrán reflexiones, notas especiales y vinculaciones a bibliografía

y sitios web.
El carácter constructivista y colaborativo del MEC nos exige que todas las actividades
realizadas por los participantes sean compartidas en los foros.

p. 6
Tomen nota*
Las actividades son opcionales y pueden realizarse en forma individual, pero siempre es
deseable que se las realice en equipo, con la finalidad de estimular y favorecer el trabajo
colaborativo y el aprendizaje entre pares. Tenga en cuenta que, si bien las actividades son
opcionales, su realización es de vital importancia para el logro de los objetivos de
aprendizaje de esta instancia de formación. Si su tiempo no le permite realizar todas las
actividades, por lo menos realice alguna, es fundamental que lo haga. Si cada uno de los
participantes realiza alguna, el foro, que es una instancia clave en este tipo de cursos,
tendrá una actividad muy enriquecedora.
Asimismo, también tengan en cuenta cuando trabajen en la Web, que en ella hay de todo,
cosas excelentes, muy buenas, buenas, regulares, malas y muy malas. Por eso, es
necesario aplicar filtros críticos para que las investigaciones y búsquedas se encaminen a
la excelencia. Si tienen dudas con alguno de los datos recolectados, no dejen de consultar
al profesor-tutor. También aprovechen en el foro proactivo las opiniones de sus compañeros
de curso y colegas.

p. 7
Modelado de Datos
L a información ha llegado a ser el eje que mueve a la mayoría de las organizaciones

hoy día. Se tiene la necesidad de mantenerla perfectamente organizada de manera
que pueda ser accedida fácilmente y por otro lado debe estar disponible todo el
tiempo (sistemas 24x7). Asimismo, la cantidad de información que se maneja
actualmente es enorme. Es por ello que resulta imprescindible la utilización de las bases de
datos.
Si observamos los diferentes escenarios donde se realizan transacciones cotidianamente,

podríamos afirmar que las bases de datos están en todas partes:
• Bancos: cuentas, préstamos, créditos, …

• Aerolíneas: reservas, pasajes, suministros, personal de vuelos, …
• Escuelas: cursos, calificaciones, horarios, …
• Negocios: compras, proveedores, ventas, clientes, devoluciones, …
• Fábricas: flujo de procesos, almacenes, envíos, …
• Recursos Humanos: empleados, puestos, salarios, impuestos, prestaciones, …
Curiosamente el uso de las bases de datos puede llegar a ser tan transparente que para
algunos pareciera que no existieran.
A partir de esta contextualización, resulta necesario que definamos Bases de Datos. Entre
las distintas definiciones existentes, consideraremos la siguiente para trabajar el resto del
curso:
“Es un conjunto de datos organizados y relacionados entre sí, con una estructura
independiente del programa que los acceda”.
Esta definición la iremos trabajando y utilizando a lo largo del curso.
¿Por qué necesitamos contar con una base de datos?
Las siguientes razones detallan la necesidad de guardar la información en una base de

datos:
Un modelo de datos es una representación gráfica que nos permite en forma tangible,
mostrar las distintas “ideas” de mi negocio u organización. Las ventajas más importantes
son las siguientes:

p. 8
✓ Permite discutir con el usuario sobre algo concreto.

✓ Queda documentado lo pactado.
✓ Permite plasmar cuáles son los límites de lo que se construirá como producto
software o sistema de información.
✓ Redundancia: los datos que se guardan en la base de datos deben estar mantenidos
en un solo lugar. Si ocurriese lo contrario, es decir se guarda el mismo dato varias
veces en distintos lugares de la base de datos, se causarían problemas como:
o Incremento del trabajo: al guardar un dato en más de un lugar, es necesario

actualizarlo y grabarlo en todos esos lugares a la vez.
o Desperdicio de espacio de almacenamiento: el dato guardado en más de
un lugar, ocupa mayor espacio de almacenamiento.
o Inconsistencia de datos: si por alguna razón, el dato no es actualizado o
guardado en todos los lugares en los que se encuentra, generaría
inconsistencia en la información almacenada.
✓ Integridad: los datos que se guardan en la base de datos deben estar validados y
relacionados, como definimos anteriormente. Es decir que si por ejemplo debemos
guardar el dato de la fecha de nacimiento de un cliente, ese dato debe ser fecha y
debemos validar que la fecha no sea futura. Por otro lado, si guardáramos además
la clasificación de ese cliente, la misma debería coincidir con cualquiera de las
clasificaciones posibles definidas en la base de datos.
✓ Atomicidad de las transacciones: La atomicidad se garantiza a través de
mecanismos de base de datos mediante los cuales se realiza el seguimiento de las
transacciones. Una transacción es considerada un evento que agrega, modifica o
elimina la información almacenada en la base de datos. Si la transacción falla por
cualquier razón, las actualizaciones que se realizaron hasta el momento serán
deshechas. Solo si la transacción llega al fin, los cambios se volverán parte de la
base de datos.
✓ Concurrencia y Aislamiento (Isolation): Mediante la concurrencia, es posible que los
usuarios accedan todos juntos a la información de las bases de datos y puedan
actualizarla de manera ordenada y simultánea. Esto es posible por medio del
aislamiento (isolation), el cual define en qué grado los usuarios pueden ver y
modificar los datos que están siendo actualizados por otros usuarios.
✓ Seguridad: la protección de los datos debe llevarse a cabo contra los fallos humanos
(intencionales o no), físicos y lógicos. Normalmente, las bases de datos tienen
mecanismos de prevención, detección y corrección. Asimismo, los datos deben ser
confidenciales; debemos recordar la existencia en Argentina de la ley de protección
de datos personales.
p. 9
“A mayor volumen de información, más necesaria se hace la

utilización de una DB “
Historia de Base de Datos
• Modelo jerárquico
El sistema jerárquico más comúnmente conocido es el sistema IMS (Information

Management System). Se trata de un diseño de IBM y otros colaboradores, que realizaron
en 1966 para el programa Apollo de la NASA. IMS aún se encuentra activo.
Esta base de datos tiene como objetivo establecer una jerarquía de fichas, de manera que
cada ficha puede contener a su vez listas de otras fichas, y así sucesivamente. Por ejemplo,
la entidad curso puede contener una lista de requisitos y otra lista de ofertas, la cual puede
contener una lista de profesores y una lista de estudiantes.
CURSO
OFERTA
REQUISITO
PROFESOR ESTUDIANTE
Para movernos por un registro de estructura jerárquica lo que se hace es posicionarse

inicialmente en la raíz de una instancia e ir navegando por sus hijos según nos convenga, a fin
de ir consultando o modificando los datos.
Una base de datos de este tipo, no permite el acceso directo a las instancias de un segmento
hijo si no es seleccionando previamente las instancias de los padres de los que depende. Por
ejemplo, no se puede seleccionar un estudiante sin previa selección de una oferta y de un curso,
lo cual implica claramente una desventaja.

p. 10
Otra desventaja es que tenemos inconsistencia de información. Por ejemplo, un profesor

puede pertenecer a más de un curso, por lo cual tenemos duplicación de información de un
mismo profesor por cada curso.
• Modelo en red
Podemos considerar al modelo de bases de datos en red como de una potencia intermedia
entre el jerárquico y el relacional, que estudiaremos más adelante. Su estructura es
parecida a la jerárquica, aunque bastante más compleja, con lo que se consiguen evitar, al
menos en parte, los problemas de aquél.
La primera especificación de una norma para las bases de datos, denominada informe
CODASYL DBTG 1971, la elaboró a finales de los años sesenta el grupo de trabajo sobre
bases de datos (Database Task Group, DBTG).
Aquí, un elemento de A puede poseer varios de B, mediante el

conjunto A-B; a su vez, los de B pueden poseer a los de A, mediante
B-A, y así sucesivamente cuantas veces se quiera. Este ejemplo no
se puede hacer en el modelo jerárquico, pues el número de niveles
varía dinámicamente.
Como hemos visto, el modelo en red tiene un carácter totalmente general. En el modelo en
red no se ha especificado ningún tipo de restricción en lo que respecta a las interrelaciones.
Esto quizá haga del modelo en red un modelo tremendamente sencillo de utilizar, pero no
deja de tener un carácter general y provoca que en la práctica su instrumentación no resulte
nada fácil.
• Modelo Relacional (RDBMS)
Este es el modelo que estudiaremos en este curso, pero veamos un poco de historia…
RDBMS (Relational DB Management System) está basado en el modelo relacional cuyo

creador es Edgar Ted Codd (científico inglés) (12 reglas). Las primeras bases de datos
relacionales aparecieron en los 70s junto con la creación de SQL (Structured Query
p. 11
Language) hasta que a principios de los 80 (en 1983 para ser más específicos) aparecen
DB2 y Oracle. En 1986, ANSI e ISO lo estandarizan en SQL-86.
• Modelo Orientado a Objetos (00)
Cuando surgieron los lenguajes orientados a objetos, como C++ o Java, se pensó en una
manera de plantear ese paradigma en bases de datos, finalmente si se programaba en un
lenguaje orientado a objetos, lo más natural sería almacenar esa información de la misma
forma.
Estos modelos nacen a partir de la programación orientada a objetos (POO), que trata los
problemas desde un punto de vista realista, y modelando cada uno de ellos como si se
tratase de un conjunto de elementos u objetos que interrelacionan entre sí para solucionar
el problema.
• Modelo Orientado a Objetos Relacional (ORDBMS)
Las bases de datos orientadas a objetos tuvieron gran auge durante los 90's pero luego
todos los OODBMS se desplomaron. Por lo cual, los vendedores de DBMS comerciales
hicieron una mezcla que permitiera utilizar los aspectos del modelo relacional y del
orientado a objetos, resultando el modelo "object-relational", surgiendo así los ORDBMS.
Las OR databases incorporaron atributos, métodos, identificadores y referencias.
• XML Native Databases (Bases de datos nativas de XML)
Este modelo nace a partir del 2000 y son aquellas que respetan la estructura del documento,
se pueden hacer consultas sobre dicha estructura y es posible recuperar el documento tal
como fue insertado originalmente.
Una base de datos nativa en XML ni tiene campos, ni almacena datos atómicos, lo que ella
almacena es el documento XML, por lo tanto, a este tipo de bases de datos se les denomina
bases de datos centradas en documentos, data-centric databases

p. 12
Bases de Datos XML Nativas
• XML Enabled Databases (Bases de datos habilitadas para XML)
Estas bases de datos son aquellas que desglosan la información de un documento XML en su
correspondiente esquema relacional o de objetos
Bases de Datos Habilitadas para XML

p. 13
Tipo de Bases de Datos
Para clasificar a las bases de datos, tenemos dos categorías:
• Según la variabilidad de los datos almacenados:

o Bases de datos estáticas: éstas son bases de datos de sólo lectura,
utilizadas primordialmente para almacenar datos históricos que
posteriormente se pueden utilizar para estudiar el comportamiento de un
conjunto de datos a través del tiempo, realizar proyecciones y tomar
decisiones.
o Bases de datos dinámicas: éstas son bases de datos donde la información
almacenada se modifica con el tiempo, permitiendo operaciones como
actualización, borrado y adición de datos, además de las operaciones
fundamentales de consulta. Un ejemplo de esto puede ser la base de datos
utilizada en una farmacia, un videoclub.
• Según el contenido:
o Bases de datos de texto completo: almacenan toda la información, todas las

fuentes primarias; como, por ejemplo, todo el contenido de todas las
ediciones de una colección de revistas científicas. Otro ejemplo son las
historias clínicas con las imágenes de todos los estudios que se realiza el
paciente, así como la historia clínica y los datos personales.
o Bases de datos bibliográficas: sólo contienen una parte de la información.
Para el caso del ejemplo anterior de las revistas científicas, la información
que se registra contendría el autor, fecha de publicación, editorial, título,
edición, de una determinada publicación, etc. Puede contener un resumen o
extracto de la publicación original, pero nunca el texto completo.
“Marcas” de Bases de Datos
Existen distintas “marcas” de bases de datos en el mercado. La clave está en cuál de ellas
elegir. La respuesta es que no hay una sola que sirva y las restantes no (por algo existen
varias), sino que depende que necesitamos. Algunos de los criterios para decidir cuál nos
conviene más radica en:
✓ ¿Estamos dispuestos a pagar licencias o queremos algo gratuito?

✓ ¿Necesitamos un buen soporte técnico las 24 horas?
✓ ¿Necesitamos almacenar tablas que contengan millones de registros?
✓ ¿Qué respuesta transaccional necesitamos?
p. 14
Los que terminan decidiendo finalmente que tipo de base adquirir, en general son los
llamados Administradores de bases de datos, conjuntamente con el equipo de IT y
dependiendo del presupuesto que la organización disponga.
Los tipos de base de datos relacionales más comunes son:
✓ Oracle
✓ MySQL
✓ Informix
✓ DB2
✓ Sybase
✓ Progress
✓ Access (Que ya viene en el pack de Microsoft Office)
Modelo lógico y modelo físico
Realizar un modelo lógico y un modelo físico, implica que a partir de una idea, proyecto y/o
especificación podamos crear una base de datos cuyos datos se encuentren organizados
y relacionados entre sí. De esa forma, el comportamiento de la base de datos va a ser
independiente del programa que la acceda.
El modelo lógico va a estar más relacionado con el diseño de aquello que queramos
representar: nuestra idea, proyecto y/o especificación. Es por ello que nos va a resultar más
familiar, más legible.
A partir del modelo lógico, se generará el modelo físico, el cual estará más relacionado con
los requisitos de la base de datos a nivel físico, como veremos en otra unidad.
Ahora, ¿por qué es importante realizar estos modelos? ¿Por qué directamente no
trabajamos sobre la base de datos?
Las razones para realizar los modelos es que nos permiten:
▪ Describir la información que necesita el negocio.

▪ Prevenir y evitar errores y malos entendidos.
▪ Facilitar la discusión.
▪ Generar documentación del sistema.
▪ Fortalecer una buena práctica, etc.
En esta unidad trabajaremos con el modelo lógico.

p. 15
El primer concepto que vamos a definir es la ENTIDAD.
Vamos a considerar que una entidad puede ser cualquier persona, lugar, cosa, evento o
concepto distinguible sobre el que se mantiene información.
Por ejemplo, si nuestro proyecto es crear una base de datos de un colegio primario, ¿qué
personas, lugares, cosas, eventos quisiéramos incluir en nuestra base de datos?
Algunas personas que podrían ser los maestros, los alumnos, los empleados de limpieza,
las secretarias, la directora, etc.
Ahora pensemos en los lugares…. Podríamos considerar entonces las aulas. Y al pensar
en las aulas, surgen eventos como la asignación de un curso a un aula. Y así van a ir
surgiendo más entidades para nuestra base de datos.
Para representar una entidad en un modelo lógico vamos a utilizar un rectángulo con puntas
redondeadas y vamos a colocar el nombre de la entidad en mayúsculas y singular en la
parte superior de la entidad.
Por ejemplo:
AULA
Ahora definamos un ATRIBUTO.
El atributo es una propiedad de una entidad, es una característica que permite definir y
conocer una entidad.
Por ejemplo, consideremos las aulas. ¿Qué atributos podría tener la entidad aula? ¿Qué
características de un aula queremos representar? ¿Qué propiedades de un aula nos
permiten definirla?
Bien, podríamos considerar el número del aula, en qué piso del colegio se encuentra, qué
capacidad de alumnos tiene, si es un aula multimedia, etc.
Como el modelo lógico es más descriptivo, podemos utilizar más de una palabra para
nombrar a un atributo, por ejemplo, Capacidad de Alumnos. Además, cuando nosotros
definimos atributos, tenemos que clasificarlos como obligatorios u opcionales. Para
representar un atributo obligatorio se utiliza una estrella o asterisco pequeño y se coloca el
p. 16
nombre del atributo en letra minúscula. Por otro lado, para representar un atributo opcional
se utiliza un círculo pequeño antes del nombre del atributo en letra minúscula.
Por ejemplo:
AULA
* Número
* Piso
* Capacidad de Alumnos
O Multimedia
Definamos ahora otro concepto: INSTANCIA. La instancia es una ocurrencia simple de una
entidad y contiene valores específicos para esa entidad.
Es decir, si asignamos valores a los atributos de una entidad, estamos representando una
instancia. Claro está que una entidad puede tener muchas instancias.
Para clarificar un poco mejor consideremos nuestro ejemplo anterior. En un colegio puede
haber muchas aulas. Para representar cada aula, usamos instancias. Las aulas se numeran
por piso.
Por ejemplo, tenemos el aula número 1, en la planta baja, donde pueden ingresar 50
alumnos y que no es del tipo multimedia. Estos valores representan una instancia.
Si queremos representar otra aula, entonces es otra instancia. Y así….

p. 17
AULAS Instancia 1 Instancia 2 Instancia 3 Instancia 4
NÚMERO 1 2 1 2
PISO PB PB 1 piso 1 piso
CAPACIDAD
de
ALUMNOS 50 40 30 30
MULTIMEDIA no no si Si
Para representar instancias no adoptamos un formato en particular. Asimismo, en el caso

anterior, se debe tener en cuenta que podríamos representar muchísimas instancias.
Nosotros estaremos trabajando con ejemplos pequeños, pero imaginemos una base de
datos de una empresa de telecomunicaciones famosa que registra los llamados de sus
clientes. ¿Se imaginan la cantidad de instancias que deben guardar?
Como mencionamos en la historia de las bases de datos, nosotros estudiaremos durante

este curso las bases de datos relacionales. Y es por ello que nos interesa definir el concepto
que le da nombre a este tipo de base de datos: RELACIÓN.
Una relación es una conexión que nos va a indicar un vínculo entre dos entidades.
Es decir, por ejemplo, las aulas van a tener alumnos. Entonces si tenemos ambas entidades
debemos relacionarlas y de esta forma indicamos que existe un vínculo entre ellas.
Para representar una relación, lo indicaremos por medio de una línea, que una, ambas
entidades y vamos a describir la relación por medio de una frase verbal.
Para nuestro ejemplo, podríamos considerar como frase verbal que el aula “contiene”
alumnos.

p. 18
AULA ALUMNO
* Número * DNI
* Piso * Nombre y Apellido

Contiene
* Capacidad de Alumnos * Domicilio
O
O
Multimedia Celular
Para definir una relación se utiliza el concepto MODALIDAD, la cual indica que una relación
puede ser optativa u obligatoria. En el caso de que la relación sea optativa se utiliza un
círculo. En el caso que la relación sea obligatoria, se utilizará un “palito”. Representa el
número mínimo de instancias entre 2 entidades.
Para continuar con la representación de una relación, agregamos otro concepto que es la
CARDINALIDAD, la cual indica el número máximo de instancias de una entidad que se
relaciona con el número de instancias de la otra entidad. La cardinalidad puede ser cero,
una o muchas.
Para poder entender un poco mejor este concepto, vamos a revisar primero los diferentes
casos que existen tomando otro ejemplo la relación entre cliente y proveedor:
Lo más importante es entender que las relaciones son bidireccionales. Se leen de izquierda
a derecha y de derecha a izquierda.
Siempre es recomendable, utilizar la palabra “cada” cuando se construye las relaciones.
Veamos un ejemplo…
Cliente Proveedor

p. 19
Cada cliente puede tener 1, ninguno, o muchos proveedores. El “puede” marca que la
relación desde cliente a proveedor es opcional, y que la cardinalidad es 1 o muchos.
Leamos ahora de derecha a izquierda…
Cliente Proveedor
Cada proveedor puede o no tener asociado 1 cliente, y si tiene asociado 1, es solo uno.
El ejemplo final sería el siguiente…
Cliente Proveedor
En el siguiente ejemplo las cosas cambian un poco…y veremos varios ejemplos más…
Cliente Proveedor
Cada cliente tiene 1 proveedor o muchos, y cada proveedor tener asociado1 y solo 1 cliente.

p. 20
Cliente Proveedor
Cada cliente puede tener 1 proveedor y solo uno, cada proveedor puede tener 1 cliente y
solo uno.
Cliente Proveedor
Cada cliente tiene 1 y solo 1 proveedor. El “tiene” marca la obligatoriedad de esa parte de
la relación. Cada proveedor, puede tener un cliente y solo uno.
Cliente Proveedor
Cada cliente puede tener 1 o muchos proveedores o ninguno, y cada proveedor tiene si o
si 1 cliente asociado.
Cliente Proveedor
Cada cliente tiene 1 y solo 1 proveedor, y cada proveedor tiene 1 o muchos clientes.

p. 21
Cliente Proveedor
Cada cliente tiene un solo proveedor, y cada proveedor puede tener 1 o ningún cliente.
Cliente Proveedor
Cada cliente tiene un solo proveedor y cada proveedor tiene un solo cliente asociado.
Vamos a revisar algunos ejemplos a fin de clarificar un poco más la representación de una
relación por medio de la modalidad y la cardinalidad.
Ahora practiquemos un poco con más ejemplos todavía…como más ejemplos ?...sí!!! más
ejemplos !!!
Si un aula contiene ningún alumno, 1 o muchos, y si el alumno puede aún no estar asociado
a un aula, pero si lo está es a una sola, la relación sería…
AULA ALUMNO
* Número * DNI
* Piso contiene
*Nombre y Apellido
* Capacidad * Domicilio
O Multimedia O Celular

p. 22
De esta forma estamos diciendo que un aula puede contener a cero o muchos alumnos.
Ahora continuemos la representación, pero analizando la entidad alumno. Si consideramos

una instancia de alumnos, ¿con cuántas instancias de la entidad aula se relacionará?
Supongamos que un alumno puede asistir en su vida escolar a diferentes aulas (sino que
aburrido sería, ¿no?). Entonces podríamos decir que un alumno puede relacionarse con
muchas aulas. Y que las aulas pueden tener muchos alumnos.
Veamos como lo representamos:
AULA ALUMNO
* Número * DNI
contiene
* Piso * Nombre y
Apellido
* Capacidad
O
* Domicilio
Multimedia
O Celular
Y de esta forma queda representado, donde podemos ver que la relación es opcional
(modalidad) y que un alumno puede estar en varias aulas y un aula puede contener a cero
o muchos alumnos (cardinalidad).
Veamos otro ejemplo más. Consideremos que el colegio cuenta con personal y que ese
personal puede ser: docentes, secretarias, directivos, limpieza, etc… Es decir que el
personal tiene una clasificación.
Entonces ¿Qué entidades tenemos? Serían personal y clasificación

p. 23
¿Qué atributos tiene el personal? Bueno supongamos nombre y apellido, sueldo y fecha de
ingreso ¿Y qué atributos tiene la clasificación? Podríamos pensar en una descripción de
esa clasificación.
¿Cómo representamos la modalidad de la relación? Como decíamos, si el personal tiene

una clasificación, entonces la relación va a ser obligatoria.
¿Y cómo representamos la cardinalidad de la relación? Veamos… Una instancia de la

entidad personal se relaciona con una sola instancia de la entidad clasificación. Es decir,
que alguien de personal puede ser de limpieza. O puede ser docente. O puede ser
secretaria… Pero no puede tener varias clasificaciones al mismo tiempo.
Revisemos la otra parte…. Una instancia de la entidad clasificación puede clasificar a más
de una instancia de la entidad personal. Es decir, podría tener muchos docentes, con lo
cual tengo más de una instancia de personal que se clasifica como “docente”.
La representación sería:
PERSONAL CLASIFICACIÓN
* Nombre * Descripción
* Apellido clasifica
* Sueldo
* Fecha de ingreso
Entendamos también que quizá no todas las instancias de “clasificación” van a tener al
menos una persona asociada, por eso el círculo en una parte de la relación.
Veamos un caso más.
Si por ejemplo se quiere guardar un registro de las entrevistas que se le realizaron al

personal a partir del año 2013.

p. 24
Podríamos generar una entidad que se llame entrevista donde guardaríamos el apellido del
entrevistado, la fecha y el detalle de la entrevista. Por último, podríamos guardar el puesto
otorgado, pero ese atributo sería optativo ya que no todos los entrevistados obtendrán un
puesto.
Analicemos un poquito más…. ¿Cómo va a ser la modalidad de la relación? Bueno, si

decimos que las entrevistas comienzan a guardarse en la base de datos a partir del 2013,
quiere decir que no tenemos las entrevistas de todo el personal. Por otro lado, no todos los
entrevistados forman parte del personal, por lo cual no todas las entrevistas se relacionan
con el personal ya que podría suceder que no hubiese sido una entrevista exitosa. En
conclusión, la modalidad será optativa.
¿Y la cardinalidad? Una instancia de la entidad personal se puede relacionar con cero

(porque su entrevista fue anterior al 2013) o una entrevista. Y una instancia de la entidad
entrevista se puede relacionar con cero (porque no forma parte del personal) o una instancia
de personal.
Por lo cual la relación quedaría de la siguiente manera:
PERSONAL
ENTREVISTA
* Nombre
* Apellido del entrevistado
* Apellido
* Fecha
* Sueldo
* Detalle de la entrevista
* Fecha de ingreso o Puesto otorgado
Ahora, supongamos que el director pide que se guarden las entrevistas de todo el personal
para saber cuándo fueron entrevistados y el detalle de la entrevista. ¿Qué cambiaría de la
relación anterior?
En relación a la cardinalidad, lo que cambiaría es que una instancia del personal siempre
se relacionaría con una entrevista. Por otro lado, una instancia de la entidad entrevista

p. 25
puede relacionarse o no con una instancia de la entidad personal (recordemos la relación

anterior).
¿Y qué pasaría con la modalidad? Podríamos decir que puede ser obligatoria y optativa.
¿Por qué? La entidad personal siempre se relaciona con la entidad entrevista, pero la
entidad entrevista se relaciona a veces. Entonces…. ¿Cómo lo resuelvo? Existen distintas
formas de representar este comportamiento de la modalidad; nosotros vamos a optar por
darle prioridad a la entidad más importante para nuestro modelo, que sería personal.
Entonces definimos la modalidad como obligatoria.
PERSONAL
ENTREVISTA
* Nombre
tuvo * Apellido del entrevistado
* Apellido
* Fecha
* Sueldo
* Fecha de o Puesto otorgado
ingreso
Integridad Referencial
Hasta ahora, definimos que es una entidad, vimos que se describe a partir de atributos y
que se vincula con otras entidades a partir de relaciones.
Ahora vamos a indagar un poco más sobre estos tres conceptos.
Si por ejemplo consideramos la entidad personal de nuestro ejemplo:

p. 26
PERSONAL
* Nombre
* Apellido
* Sueldo
* Fecha de ingreso
¿Qué sucedería si tuviéramos dos o más personas con el mismo nombre y apellido? ¿Y si
lo mismo sucediera con dos o más alumnos? ¿Cómo haríamos para identificarlos?
¿Tendríamos que ir revisando el resto de los atributos?
Para resolver estos problemas, se busca una forma de identificar unívocamente a las
entidades. Así no tendríamos que esforzarnos demasiado en identificar instancias.
Para ello, vamos a definir el concepto de CLAVE CANDIDATA. La clave candidata es un

atributo o un grupo de atributos obligatorios que identifican unívocamente a la entidad.
Pensemos en el personal. ¿Qué atributos podríamos agregar para identificar al personal?

Podría ser por ejemplo el legajo del personal, ya que es único y obligatorio. También podría
ser el cuil o el tipo y número de documento.
Entonces como claves candidatas identificamos:
- Legajo
- Cuil
- Tipo y número de documento

p. 27
PERSONAL
* Nombre
* Apellido
* Sueldo
* Fecha de ingreso
* Legajo
* Tipo de Doc.
* Nro. de Doc.
Ahora agreguemos dos definiciones más: CLAVE PRIMARIA Y CLAVE ALTERNATIVA. La
* Cuilcandidata que seleccionamos para representar a nuestra
clave primaria es aquella clave
entidad. La misma es representada con un signo numeral delante del nombre del atributo y
la colocaremos al principio de la lista de los atributos. Las claves alternativas serán aquellas
claves candidatas que quedaron descartadas. Por ahora no vamos a identificarlas de forma
gráfica, pero si volveremos sobre este concepto en otra de las unidades.
Para el caso del personal, podríamos elegir el legajo como clave primaria y el resto de los
atributos como claves alternativas, con lo cual nuestra entidad quedaría de esta manera:
PERSONAL
# Legajo
* Nombre
* Apellido
* Sueldo
* Fecha de ingreso
* Tipo de Doc.
* Nro. de Doc.
* Cuil
p. 28
También podría suceder que no existan claves alternativas.
Pensemos en la entidad aula que citamos en uno de los ejemplos:
AULA
* Número
* Piso
* Capacidad
O Multimedia
¿De qué manera podríamos identificar a un aula?
Veamos las instancias que expusimos anteriormente:
AULAS Instancia 1 Instancia 2 Instancia 3 Instancia 4
NÚMERO 1 2 1 2
PISO PB PB 1 piso 1 piso
CAPACIDAD 50 40 30 30
MULTIMEDIA no No si Si
El número de aula se repite, es decir si el número fuera PK ya no sería único. Recordemos

que las aulas se numeran por piso.
Lo mismo sucede con el piso y con la capacidad.
El atributo multimedia no es obligatorio con lo cual no serviría.
¿Entonces?

p. 29
Bueno, si las aulas se numeran por piso, podemos definir una clave primaria que se
componga de número y piso. Ambos atributos son obligatorios y juntos definen
unívocamente a la entidad aula.
De esta forma, quedaría representado de la siguiente manera:
AULA
# Número
# Piso
* Capacidad
O Multimedia
En este caso, no encontramos otras posibles claves candidatas así que no hay claves
alternativas.
Consideremos un último caso, la entidad clasificación, que según veníamos viendo quedó
definida de la siguiente forma:
CLASIFICACIÓN
* Descripción
En este caso solo tenemos el atributo descripción y como veníamos viendo, podríamos
agregar algún atributo más si fuese necesario.
Revisemos…. La descripción es un atributo obligatorio y además parecería que no se repite,

¿no es cierto? Es decir, podríamos considerar como instancias:

p. 30
CLASIFICACIÓN Instancia 1 Instancia 2 Instancia 3 Instancia 4
DESCRIPCIÓN Docente Auxiliar Limpieza Administrativo
Pues, según vemos sería un atributo obligatorio y único.
Ahora… según estudiaremos más adelante y si aún indagaran mucho más sobre la
administración de una base de datos, sabrían que no es conveniente físicamente asignar
un atributo “variable” (en tamaño, cantidad de caracteres) a una clave primaria. Es decir,
para guardar el atributo descripción necesitamos que el campo sea variable ya que no
saben cuánto espacio necesita y además todas las descripciones no miden lo mismo.
Cuando esto sucede, generamos un código que identifique a cada descripción y que podría
ser tanto numérico como alfanumérico, por ejemplo:
CLASIFICACIÓN Instancia 1 Instancia 2 Instancia 3 Instancia 4
CÓDIGO 1 2 3 4
DESCRIPCIÓN Docente Auxiliar Limpieza Administrativo
De esta forma, entonces nuestra clave primaria quedará definida con el atributo código:
CLASIFICACIÓN
# Código
* Descripción
Como el ejemplo anterior, no encontramos otras posibles claves candidatas así que no hay
claves alternativas en la entidad Clasificación.

p. 31
Finalmente, sobre el concepto de clave primaria me interesa que recuerden algo muy
importante: TODAS LAS ENTIDADES DEBEN TENER UNA CLAVE PRIMARIA.
Sobre este recordatorio les debo aclarar que pueden encontrar entidades que no tengan
definidas claves primarias, algunas están bien y otras no; pero, por los ejemplos que
trabajaremos durante el curso, deben acordarse de esta regla. Y es por ello que debemos
recordar que cada entidad debe tener una clave primaria a fin de poder identificar cada
instancia de una forma única.
Relacionado a la clave alternativa, revisemos otro concepto adicional: INVERSION ENTRY.

El Inversion Entry está compuesto por uno o más atributos que se consideran de mucha
utilización y no fueron definidos como clave primaria (PK) ni alternativa (AK).
Revisemos el caso del personal. Si miramos nuevamente la entidad:
PERSONAL
# Legajo
* Nombre
* Apellido
* Sueldo
* Fecha de ingreso
* Tipo de Doc.
* Nro. de Doc.
Pensemos… ¿Qué atributos de la entidad Personal podrían ser frecuentemente accedidos?
* Cuil
Si por ejemplo quisiéramos un listado del personal, ¿Qué atributos serían los más
frecuentemente utilizados y consultados? Podría ser el nombre y el apellido.
Son dos atributos que se podrían acceder varias veces de distintas formas.
Entonces podemos establecer que los atributos de nombre y apellido son Inversion Entry.
Veamos el caso del aula:

p. 32
AULA
# Número
# Piso
* Capacidad
O Multimedia
Supongamos que cuando queremos asignar un curso a las aulas se revisa la capacidad de
acuerdo a la cantidad de alumnos inscriptos. Entonces podríamos decir que como el atributo
capacidad es frecuentemente utilizado, lo definimos como Inversion Entry.
Tanto este concepto como el de clave alternativa no serán presentados en el modelo lógico
y los volveremos a mencionar más adelante.
Veamos otra clave más llamada foránea o Foreign Key (FK). Esta clave se genera cuando
armamos una relación entre dos entidades y se define como “una clave primaria de una
entidad que es heredada por otra entidad a través de una relación”. La misma quedará
definida de acuerdo a quién sea el padre de la relación y se representa en el modelo lógico
simplemente colocando (FK) detrás del nombre del atributo.
Veamos el caso por ejemplo del personal y su clasificación.
PERSONAL
# Legajo
* Nombre
clasifica CLASIFICACIÓN
* Apellido
# Código
* Sueldo
* Descripción
* Fecha de ingreso

p. 33
En este caso la relación es “clasifica”. Es decir que la entidad CLASIFICACIÓN está

clasificando a la entidad PERSONAL.
Con lo cual el padre de la relación es CLASIFICACIÓN, ya que de acuerdo a las

clasificaciones que existan, el personal quedará clasificado.
Es decir, si no tuviéramos clasificaciones, la relación no existiría. Por lo cual, la entidad más

importante en esta relación es la clasificación.
Entonces, una vez que definimos quién es el padre de la relación, tenemos que generar la
clave foránea.
Según la definición, la clave primaria será heredada por la entidad hijo. Esto quiere decir
que la clave primaria de Clasificación será heredada por la entidad Personal.
Con lo cual, en nuestro caso quedaría de la siguiente manera:
PERSONAL
clasifica
# Legajo
* Nombre
CLASIFICACIÓN
* Apellido
# Código
* Sueldo
* Descripción
* Fecha de ingreso
* Cód. de Clasif (FK)
Es necesario hacer dos aclaraciones. En primer lugar, como es un atributo, al generar una
FK debemos definir si es obligatoria u optativa. En segundo lugar, no es necesario mantener
el nombre de la PK del padre.

p. 34
Para nuestro ejemplo, nos interesa que la clasificación sea obligatoria y llamamos al atributo
como “Cod. de Clasif “en lugar de “Código” como figura en la entidad padre, de forma que
al ver la entidad Personal se entiende a que código se refiere.
Antes de revisar más ejemplos, es necesario que clasifiquemos esta relación como NO
IDENTIFICATORIA. Una relación es de este tipo cuando la FK no forma parte de la PK del
hijo. En este caso, código de clasificación no es PK.
Y va a ser IDENTIFICATORIA cuando suceda lo contrario, como veremos en los siguientes

ejemplos.
Tomemos otro ejemplo más: la entidad Sueldo Personal, donde registramos los sueldos de
todo el personal.
SUELDO
PERSONAL
* Legajo
* Mes y Año
* Monto
* Premio
Si definimos el legajo como PK, no sería un atributo único ya que una persona cobra un
monto todos los meses. Por lo cual para definir la PK utilizamos también el mes y el año:
SUELDO
PERSONAL
# Legajo
# Mes y Año
* Monto
* Premio

p. 35
Veamos la relación entre Sueldo Personal y Personal:
PERSONAL
SUELDO PERSONAL
# Legajo
cobra
* Nombre # Legajo
* Apellido # Mes y Año
* Domicilio * Monto
* Fecha de ingreso * Premio
La relación sería “cobrar” donde la entidad padre sería el personal y la entidad hijo sería el
sueldo personal. Sin personal, no habría sueldos y no existiría esta relación.
Entonces la clave primaria de personal sería clave foránea de la entidad sueldo personal.
PERSONAL
SUELDO
# Legajo PERSONAL
* Nombre # Legajo (FK)

cobra
* Apellido # Mes y Año
* Domicilio * Monto
* Fecha de ingreso * Premio
*Cód. de Clasif (FK)

p. 36
Esta relación donde la clave primaria del padre (legajo) forma parte de la clave primaria del
hijo se clasifica como IDENTIFICATORIA, como fue definida anteriormente.
Ahora… ¿qué sucede con las relaciones de uno y/o cero a uno y/o cero?
Revisemos el ejemplo entre Personal y Entrevista:
PERSONAL
ENTREVISTA
# Legajo
* Nombre
* Apellido del entrevistado
* Apellido tuvo
* Fecha
* Domicilio
* Fecha de ingreso
o Puesto otorgado
*Cód. de Clasif (FK)
En primer lugar, antes de pensar en la relación, ¿qué nos falta resolver?
Bueno, está faltando la PK de la entidad Entrevista.
Pensemos en las instancias que podría tener según está definida:
ENTREVISTA Instancia 1 Instancia 2 Instancia 3 Instancia 4
APELLIDO GOMEZ PURITA ORDIZ GOMEZ
FECHA 03/02/2013 03/02/2013 10/02/2013 11/02/2013
Cumplió No tiene
los disponibilidad No le interesa Cumplió los
DETALLE requisitos. horaria. el puesto. requisitos.
PUESTO
OTORGADO Docente Docente

p. 37
Por lo que podemos ver, el apellido se puede repetir, aun siendo distinta la persona que se
entrevista y la fecha también, ya que se puede entrevistar más de una persona por día.
Una forma de identificar a una persona podría ser por DNI por ejemplo.
Ahora… ¿y si la persona volviera dentro de un tiempo a tener otra entrevista para el mismo
u otro puesto?
Entonces podríamos combinar la PK, agregando además la fecha de la entrevista, por lo

cual la entidad Entrevista quedaría de la siguiente forma:
PERSONAL ENTREVISTA
# Legajo # Nro. de DNI
* Nombre tuvo # Fecha de entrevista
* Apellido * Apellido del entrevistado
* Domicilio * Detalle de la entrevista
Ahora revisemos como definir la FK. Una manera sería definir como padre de la relación a
la entidad Personal, donde entonces la FK quedaría definida en el hijo (entidad Entrevista)
como opcional (ya que no todos los entrevistados son parte del personal):

p. 38
PERSONAL ENTREVISTA

* Fecha de ingreso o Legajo (FK)

Otra manera sería definir como padre de la relación a Entrevista, donde la FK quedaría en
la entidad personal:
PERSONAL ENTREVISTA
* DNI (FK)
* Fecha entrevista (FK)

p. 39
Estas decisiones se toman en base al modelo con lo que estemos trabajando y solo sucede
con las relaciones en las que la cardinalidad es de uno o cero a uno o cero.
Es decir, solo cuando tengamos esa cardinalidad, podemos definir la FK en una (solo una)
de las dos entidades, según creamos que sea más conveniente.
Ahora… ¿qué sucede con las relaciones de muchos a muchos?
AULA ALUMNO
# Número # Legajo
# Piso * Nombre y Apellido

contiene
Las relaciones muchos a muchos, como este ejemplo, se pueden representar lógicamente
pero no físicamente.
De acuerdo a lo visto, la representación lógica sería lo siguiente:
AULA ALUMNO
# Número # Legajo
# Piso * Nombre y Apellido
contiene
* Legajo (FK) * Número del Aula (FK)
* Piso del Aula (FK)

p. 40
Pensemos porque físicamente no

puede representarse.
Bueno, sería algo así como la

leyenda del huevo y la gallina.
¿Quién surge primero?...
Físicamente se resuelve generando

una nueva entidad, pero nosotros
vamos a hacerlo directamente en el
modelo lógico.
Eso quiere decir que debemos

recordar siempre que, para diseñar
un modelo de base de datos, las
relaciones muchos a muchos
quedarán prohibidas, debiendo
generar una nueva entidad entre ambas, que clasificaremos a continuación.
Entonces nuestro modelo quedaría de la siguiente forma, donde la nueva entidad que
generamos quedará definida mediante la relación entre estas entidades.
AULA CURSOS Asiste ALUMNO
# Número # Legajo Alumno (FK) # Legajo

Contiene
# Piso # Nro de Aula (FK) * Nombre y Apellido
a
* Capacidad # Piso de Aula (FK) * Domicilio
O
Multimedia * Fecha de inicio O
Celular
O
Fecha de fin
O
Celular

p. 41
En este caso llamaremos a la nueva entidad Cursos y su PK queda definida a partir de las
PKs de las entidades Aula y Alumno (no nos olvidemos que la relación define también la
FK).
Además, en la nueva entidad podemos agregar más atributos que nos interesen, como por
ejemplo la fecha en que inicia el curso y la fecha de fin.
Por último, vamos a definir otro tipo de relación: recursiva. Una relación es recursiva cuando
el padre es la misma entidad que el hijo. Es decir, es una relación que se define sobre sí
misma.
Supongamos que, en nuestro colegio, todos los docentes tienen coordinador de área. Es
decir, un docente que se encarga de coordinar entre los docentes diferentes temas que
deben tratarse en el aula, como por ejemplo talleres transversales, discusión de temas
nuevos, etc. Entonces nos interesa saber de un docente quién es su coordinador.
Pensemos en ejemplos de instancias posibles donde tenemos dos coordinadores y cuatro

docentes:
Instancia Instancia Instancia Instancia Instancia Instancia

PERSONAL 1 2 3 4 5 6
LEGAJO 1000 1001 1002 1003 1004 1005
APELLIDO Gutiérrez Frachi Wherli Bellota Méndez Pendre
NOMBRE Cristian Noelia Carlos Alicia Cristina Mauricio
Defensa Caffarena Juramento Pujol 644 Alberdi Larralde

DOMICILIO 219 51 2291 5751 6309
FECHA DE 12/05/200 12/05/200 01/03/200 05/06/200 10/10/201

ING. 1 12/05/2001 1 2 3 2
COD 2 2
CLASIF. 1 1 2 2
LEGAJO 1000 1001

COORD. 1000 1001

p. 42
Si pensamos en un organigrama de estas seis instancias sería algo así:
1000 1001
Cristian Noelia
Gutierrez Frachi
1002 1003 1004 1005
Carlos Alicia Cristina Mauricio

Wherli Bellota Pendre
Mendez
Ahora veamos como quedaría el modelo de la entidad personal:
PERSONAL
# Legajo
* Nombre
* Apellido
* Domicilio
* Fecha de ingreso

O Celular
O Legajo Coordinador (FK)

p. 43
En primer lugar, recordemos que no todo el personal es docente con lo que no todos serían
coordinadores o coordinados.
Luego pensemos, ¿Cómo sería la modalidad? Optativa. No solo por la aclaración anterior
sino también porque un coordinador no tiene coordinador. Es decir, solo el personal que
tiene un coordinador, tendría un valor en el atributo legajo coordinador. El resto (los no
docentes y coordinadores) tendrían ese atributo vacío.
¿Y la cardinalidad? Por un lado, una instancia de la entidad personal tendría cero o ningún
coordinador. Por otro lado, una instancia de la entidad personal estaría coordinando cero o
muchos docentes.
Clasificación de entidades
• Independiente: una entidad es independiente cuando se define a partir de atributos

propios.
Entre los ejemplos citados, podemos decir que la entidad Clasificación es
independiente, ya que los atributos son exclusivos de esa entidad.
CLASIFICACIÓN
# Código
* Descripción
• Asociativa: una entidad es asociativa cuando se genera a partir de dos o más

relaciones. Este tipo de entidad es justamente la que definimos en el ejemplo
anterior, donde se genera a partir de las relaciones muchos a muchos. En nuestro
ejemplo sería:

p. 44
CURSOS
# Legajo Alumno (FK)
# Nro de Aula (FK)
# Piso de Aula (FK)
* Fecha de inicio
O
Fecha de fin
O
Celular
• Dependencia Simple o Débil: se genera a partir de una relación con otra entidad
donde además se encuentran atributos propios.
Entre las entidades que describimos, podemos decir que la entidad Sueldo Personal
se clasifica como Dependencia Simple o Débil ya que su PK está formada por
Legajo, que es un atributo que hereda a partir de la relación con Personal y además
su PK está definida por mes y año que es un atributo propio.
SUELDO PERSONAL
# Legajo (FK)
# Mes y Año
* Monto
* Premio
• Jerarquía de Generalización: es un agrupamiento jerárquico de entidades que

comparten características comunes.
Pensemos si en el colegio se aceptaran alumnos por intercambio. Tendríamos
alumnos cotidianos y alumnos por intercambio. Pero ambas categorías compartirían
los atributos de un alumno como el nombre y apellido, el domicilio y el celular. Sin

p. 45
embargo, cada tipo de alumno tendría atributos distintos; por ejemplo, en el caso de
los alumnos por intercambio, nos interesaría conocer cuál es el país de origen,
cuando ingresa al colegio y cuando egresa. En cambio, de los alumnos cotidianos,
no necesitamos conocer esos datos, pero por ejemplo si nos gustaría saber si estuvo
en un colegio anterior.
Entonces en lugar de tener un modelo como el siguiente donde tenemos atributos

repetidos (en este caso nombre y apellido, domicilio y celular):
ALUMNO COTIDIANO ALUMNO por INTERCAMBIO
# Legajo # Legajo
* Nombre y Apellido * Nombre y Apellido
* Domicilio * Domicilio
O
O
Celular Celular
* Colegio Anterior * País de Origen
* Fecha de ingreso
O
Fecha de egreso
Se genera la jerarquía de generalización, donde se agrupan los atributos comunes

(en este caso nombre y apellido, domicilio y celular) en una entidad que se denomina
SUPERTIPO (en este caso alumno). El resto de los atributos se encontrarán en
entidades que se denominan SUBTIPO (en este caso cotidiano e intercambio) donde
la clave primaria se hereda de la entidad SUPERTIPO.

p. 46
ALUMNO
# Legajo
* Nombre y Apellido
* Domicilio
O
Celular
COTIDIANOS INTERCAMBIO
# Legajo (FK) # Legajo (FK)
* ColegioAnterior * País de Origen
* Fecha de ingreso
O
Fecha de egreso
Constraints
Como lo indica su traducción al español, constraint es una restricción. En nuestro caso, lo

que asegura un constraint es que se cumpla la integridad referencial que estamos
definiendo.
Hasta el momento hemos visto algunas de ellas. Pensemos….
La primera restricción que mencionamos es cuando clasificamos un atributo como

obligatorio. Esa restricción se denomina NOT NULL.
Una restricción muy importante que mencionamos es la PK. La PK asegura que el o los
atributos identifiquen unívocamente a esa entidad y que sean obligatorios.

p. 47
Otra restricción importante vista es la FK, donde nos asegura que, en una relación, el hijo
solo contenga valores que se encuentren definidos en el padre.
¿Recuerdan la clave alternativa? Ese atributo que podría haber sido escogido como clave
primaria. Bueno, también se lo nombra como Unique Key.
En este curso solo trabajaremos con estas cinco restricciones:
- NOT NULL
- PK
- FK
- UNIQUE KEY (UK)
- CHECK
Definamos entonces que es un check. Esta restricción nos va a permitir controlar los valores
que puede tener un atributo.
Entonces, por ejemplo, yo podría controlar los valores que puede tener el atributo monto de
la entidad Sueldo Personal.
SUELDO PERSONAL
# Legajo (FK)
# Mes y Año
* Monto
* Premio
¿De qué forma? Podría controlar que el monto sea siempre mayor a 0. De esa forma, evito
que se guarden valores negativos.
La definición de CHECK sobre la entidad Sueldo Personal sería:
“Monto > 0”

p. 48
De esa forma controlamos que el monto no contenga valores negativos.
Este tipo de definiciones no vamos a escribirlas en el modelo, pero si volveremos sobre

este tema más adelante.
Por último, internamente, todas las restricciones tienen nombres para poder ser
manipuladas. Por ahora no vamos a otorgar nombres a las mismas, pero volveremos sobre
este tema más adelante.
Dominio
El dominio lo utilizaremos para definir un conjunto de valores que serán aplicados a las
propiedades de un atributo.
Veamos cómo utilizarlo. Recordemos las entidades Alumno y Personal.
ALUMNO
# Legajo
* Nombre y Apellido
* Domicilio
O Celular
* Tipo de Documento
* Nro de Documento
PERSONAL
# Legajo
* Nombre y Apellido
* Domicilio
* Fecha de ingreso
* Tipo de Documento
* Nro de Documento

p. 49
Si nosotros guardáramos el tipo de documento, podríamos construir una constraint que

validara que los valores sean únicamente DNI, LE, LC, PAS y CI.
Entonces lo que hacemos es crear un dominio. El dominio lo llamaremos “tipo de

documento” y se aplicaría a todos los atributos que necesitemos validar. No solamente a
las entidades Alumno y Personal. Si llegaran a existir más entidades, podríamos utilizarlo.
Es una forma de definir qué valores posibles tiene el atributo.
Ahora…. Algunos se preguntarán porque no utilizamos la constraint que acabamos de ver:

check.
¡No está mal! La diferencia es que el dominio se crea a nivel global del modelo y el check
lo definimos por cada instancia.
Auditoria
Este tema es muy importante, aunque uno crea que no es necesario. Cuando nosotros
creamos un modelo de datos, tenemos que pensar que toda la información que nosotros
guardemos sobre cada entidad nos sirve para tomar decisiones en un futuro.
Por ejemplo, supongamos que el colegio realiza un análisis de los estudiantes que recibe
por intercambio. Recordemos la entidad:
INTERCAMBIO
# Legajo (FK)
* País de Origen
* Fecha de ingreso
O
Fecha de egreso
Supongamos que, al revisar las instancias, se percibe que la mayoría de los alumnos son
de Francia. En base a ello, el colegio toma la decisión de fomentar el intercambio con
estudiantes de Inglaterra a fin de mejorar el nivel de inglés de sus alumnos.
Al tomar la decisión de fomentar el intercambio en Inglaterra, el colegio quiere saber por

qué razón los estudiantes de intercambio eligieron su colegio y si recomiendan realizar el
intercambio.

p. 50
¡¡Pero… con los atributos que tiene no puede hacerlo!!
¿Qué información debería haberse guardado?
Por ejemplo:
INTERCAMBIO
# Legajo (FK)
* País de Origen
* Fecha de ingreso
* Motivos de intercambio
* Domicilio de estadía
* Teléfono de estadía
O
Fue hospedado por flia escolar?
O
Fecha de egreso
Es decir, toda la información que se necesite para tomar decisiones en el futuro debe
O
MotivosSiempre
guardarse. de abandono
y cuando sea posible obtener esa información y registrarla en la base
de datos.
O
Detalle de entrevista final
Final
* Observaciones generales
Bueno hemos llegado al final de esta unidad.
Fue un recorrido intenso donde aprendimos cuál es el fin de modelar una base de datos.
Vimos un poco de historia, clasificaciones y aprendimos muchos conceptos sobre el diseño

de un modelo lógico.
El modelo lógico que vas a observar a continuación es solo un ejemplo utilizando la

herramienta Erwin…

p. 51
Utilicé una herramienta de modelado, pero se puede modelar mediante cualquier programa,
¡hasta en papel!
Espero hayas entendido todo. Si te queda alguna duda, súbila por favor al foro.
Ahora resta completar el cuestionario, instalar la base de datos en tu casa (En la siguiente
página te dice como) y si tenés ganas, ¡subir la actividad opcional!
A trabajar se ha dicho…

p. 52
Bibliografía utilizada y sugerida

Libros y otros manuscritos
• Bruce, Thomas A. Designing Quality Databases with IDEF1X Information Models.
New York: Dorset House Pub; 1992.
• Giménez, Matilde Celma, Casamayor Ródenas, Juan Carlos y Mota Herranz, Laura.
Base de datos relacionales. Madrid: Pearson-Prentice Hall; 2003.
• Kroenke, David M. Database Processing: Fundamentals, Design and
Implementation. 7° Ed. New Jersey: Prentice Hall; 2000.
• Mannino, Michael V. Administración de Base de Datos – Diseño y desarrollo de
aplicaciones. 3ª Ed. México: Mc. Graw – Hill; 2007.

p. 53
Lo que vimos:
En esta unidad, conocimos los primeros conceptos para diseñar una base de datos,
utilizando la técnica de Diagrama de Entidad Relación, más conocida como “DER”.
Incorporamos distintos tipos de bases de datos, aprendimos distintos motores que

hay en el mercado laboral, y también entendimos el concepto de “integridad
referencial” de una DB.
Lo que viene:
Ahora pasaremos a conocer en profundidad, la diferencia entre modelo lógico y
físico, aprenderemos los objetos de una DB, las distintas nomenclaturas que hay, y
lo más importante, entenderemos a que se le llama DDL – Data Definition Language
o Lenguaje de Definición de Datos y que sentencias se incluyen en él. ¡Avancemos!


Fundamentos de BasedeDatos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fundamentos de BasedeDatos

Cargado por

Copyright:

Formatos disponibles

Fundamentos de Bases de Datos

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

Consignas para el aprendizaje colaborativo

● Los foros proactivos asociados a cada una de las unidades.

Además, también se propondrán reflexiones, notas especiales y vinculaciones a bibliografía

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.

L a información ha llegado a ser el eje que mueve a la mayoría de las organizaciones

Si observamos los diferentes escenarios donde se realizan transacciones cotidianamente,

• Bancos: cuentas, préstamos, créditos, …

Esta definición la iremos trabajando y utilizando a lo largo del curso.

¿Por qué necesitamos contar con una base de datos?

Las siguientes razones detallan la necesidad de guardar la información en una base de

Centro de e-Learning SCEU UTN - BA.

✓ Permite discutir con el usuario sobre algo concreto.

o Incremento del trabajo: al guardar un dato en más de un lugar, es necesario

“A mayor volumen de información, más necesaria se hace la

Historia de Base de Datos

El sistema jerárquico más comúnmente conocido es el sistema IMS (Information

Para movernos por un registro de estructura jerárquica lo que se hace es posicionarse

Centro de e-Learning SCEU UTN - BA.

Otra desventaja es que tenemos inconsistencia de información. Por ejemplo, un profesor

Aquí, un elemento de A puede poseer varios de B, mediante el

• Modelo Relacional (RDBMS)

RDBMS (Relational DB Management System) está basado en el modelo relacional cuyo

• Modelo Orientado a Objetos (00)

• Modelo Orientado a Objetos Relacional (ORDBMS)

• XML Native Databases (Bases de datos nativas de XML)

Centro de e-Learning SCEU UTN - BA.

Bases de Datos XML Nativas

• XML Enabled Databases (Bases de datos habilitadas para XML)

Bases de Datos Habilitadas para XML

Centro de e-Learning SCEU UTN - BA.

Tipo de Bases de Datos

Para clasificar a las bases de datos, tenemos dos categorías:

• Según la variabilidad de los datos almacenados:

o Bases de datos de texto completo: almacenan toda la información, todas las

“Marcas” de Bases de Datos

✓ ¿Estamos dispuestos a pagar licencias o queremos algo gratuito?

Los tipos de base de datos relacionales más comunes son:

Modelo lógico y modelo físico

Las razones para realizar los modelos es que nos permiten:

▪ Describir la información que necesita el negocio.

En esta unidad trabajaremos con el modelo lógico.

El primer concepto que vamos a definir es la ENTIDAD.

Ahora definamos un ATRIBUTO.

Si queremos representar otra aula, entonces es otra instancia. Y así….

Centro de e-Learning SCEU UTN - BA.

AULAS Instancia 1 Instancia 2 Instancia 3 Instancia 4

PISO PB PB 1 piso 1 piso

Para representar instancias no adoptamos un formato en particular. Asimismo, en el caso

Como mencionamos en la historia de las bases de datos, nosotros estudiaremos durante

Centro de e-Learning SCEU UTN - BA.

* Piso * Nombre y Apellido

Siempre es recomendable, utilizar la palabra “cada” cuando se construye las relaciones.

Centro de e-Learning SCEU UTN - BA.

Leamos ahora de derecha a izquierda…

El ejemplo final sería el siguiente…

Centro de e-Learning SCEU UTN - BA.

Centro de e-Learning SCEU UTN - BA.