POOABD (POO Aplicada a B Datos) - RDBMS parte 1 -2020

PROGRAMACIÓN ORIENTADA A OBJETOS
PROGRAMACIÓN ORIENTADA A OBJETOS
APLICADA A BASES DE DATOS
APLICADA A BASES DE DATOS
Por
LAURA NOUSSAN LETTRY
SISTEMAS DE BASES DE DATOS RELACIONALES
Parte 1
Aviso Legal
El presente libro electrónico
se distribuye bajo
Attribution-NonCommercial-
NoDerivs 3.0 Unported
2013-2020

PROGRAMACIÓN III - POO APLICADA A BASES DE DATOS
ÍNDICE
SISTEMAS DE BASES DE DATOS RELACIONALES – PARTE 1
Introducción
1. Concepto de Base de Datos
2. Clasificación de Base de Datos.
3. Diseño Lógico y Normalización. Concepto de Diseño Lógico. Normalización:
1º, 2º y 3º Forma Normal. Claves Primarias, Claves foráneas.
4. Diseño Lógico y Físico de una base de datos. Casos Prácticos
2
3
4
6
8
FUENTES Bibliográficas Consultadas
1. C.J. DATE, Introducción a los SISTEMAS DE BASES DE DATOS 7a
Edición
(Pearson Education, 2001, México)
2. SAROKA, Raúl Horacio, Sistemas de Información en la Era Digital (Capítulos I y
II, ebook, Fundación OSDE 2002)(*)
BIBLIOGRAFÍA para el Alumno
1. Contenidos del presente apunte
2. SAROKA, Raúl Horacio, Sistemas de Información en la Era Digital (Capítulo II,
ebook, Fundación OSDE 2002)(*)
3. Software necesario: Procesador de Texto y Planilla de Cálculo
ACTIVIDADES
Puntos 1/4 Lectura, trabajos y prácticas propuestas en el Website de la
Materia y autoevaluaciones disponibles en el aula virtual
(*): website de la materia: https://lnoussanl.org/javabd/
Profesora Lic. Laura Noussan-Lettry Página 1

SISTEMAS DE BASES DE DATOS RELACIONALES – PARTE 1
INTRODUCCIÓN
Los Sistemas de Bases de Datos están presentes en toda actividad y en toda
organización. El mundo actual, con el vertiginoso desarrollo en los últimos años de
Internet y concomitantemente del comercio electrónico y del desarrollo de software
multiplataforma han hecho que los sistemas de bases de datos también avancen hacia
otros modelos, como los objetos y las Big Tables.
Los Sistemas de Bases de Datos que abordaremos para su estudio son los Modelos
Relacionales o Sistemas de Bases de Datos Relacionales, que son aquéllos que se basan
en el álgebra relacional y que ciertamente son claros dominadores aún hoy en día, tanto
en el ámbito de los servidores web y en entornos de empresas pequeñas y medianas.
Estos sistemas están en la base de la Pirámide Organizacional puesto que son utilizados
a diario para llevar a cabo las operaciones diarias de las organizaciones. Los podemos
encontrar en pequeñas, medianas y grandes empresas y organizaciones.
Sistemas BI
Sistemas para el apoyo
a la toma de decisiones
Sistemas Operacionales
o Transaccionales
Figura 1 Pirámide Organizacional
La imagen nos muestra los diferentes niveles de la Organización y su relación con los distintos
tipos de decisiones y sistemas de información. Fuente: Capítulo 2 ebook de SAROKA
Como veremos también, de esa base en la pirámide se va subiendo a otros niveles donde
aparecen otros tipos de sistemas de información, hasta llegar al nivel más elevado; sin
embargo, en estos niveles inclusive, la importancia de los sistemas operacionales sigue
siendo relevante puesto que es la fuente de información más a mano, la de la propia
organización, que es transformada y procesada junto con información de origen externo y
utilizada en los Sistemas de Apoyo para la Toma de Decisiones y en los Sistemas de Nivel
Superior.

SISTEMAS DE BASES DE DATOS RELACIONALES
CONCEPTO DE BASE DE DATOS
En primer lugar lo fundamental es entender qué es una base de datos y cómo funciona. Nos interesa este
concepto porque si bien el programa trata sobre las Bases de Datos los conceptos teóricos y prácticos
sobre este tema en particular sirven de base para su utilización con variados lenguajes de programación
y de diseño de software que permiten manipular datos como sucede con Java, PHP, Python, etc.
El fin básico de una Base de Datos es el de almacenar información que tiene valor desde
algún punto de vista para su propietario. La siguiente imagen indica la diferencia entre un
Sistema de Base de Datos y otros Sistemas de almacenamiento de información.
Los Sistemas de Bases de Datos han tenido un gran auge en los últimos años y ello se debe a sus
ventajas en relación a los sistemas que se basan en Archivos como el Excel, por ejemplo. Las ventajas se
resumen y explican seguidamente:
 las Bases de Datos nos permiten compartir datos e información;
 entre distintas aplicaciones y distintos tipos de usuarios;
 haciendo que la información esté disponible en forma rápida;
 y fundamentalmente restringida a quienes debe y pueden tener acceso a ella.
Aquí no se trata de que un usuario decide compartir sus datos con otros sino más bien de que existe una
política empresaria que decide qué datos estarán accesibles, en qué forma y en qué nivel de acceso
a los diferentes usuarios.
Cuando realmente existe dicha política en una organización la misma se ve reflejada en la práctica en la
existencia de una persona, el Administrador de Bases de Datos o DBA, que en base a esa
política o visión de negocio, es quien configura la Base de Datos en vista a sus objetivos.
También existe un administrador por software que se llama habitualmente Sistema Administrador
de Bases de Datos o DBMS.
En las bases de datos tenemos una serie de archivos relacionados entre sí que se llaman tablas. Además
estos sistemas permiten establecer un orden de accesos a la información teniendo en cuenta la jerarquía
del personal de la empresa. De esta forma la seguridad es fundamental y con ello se consigue compartir
los datos pero también restringir su acceso. Por ejemplo, un empleado de almacenes debe poder
consultar los datos de los artículos y mercaderías pero no debería por qué tener acceso a los datos de los
sueldos del personal. Por otro lado la información puede estar disponible en forma muy rápida mediante
la ejecución de consultas sobre la base de datos. Todo lo referente al manejo de archivos (las tablase y
vistas de una base de datos) está gestionado por el Sistema Administrador de la Base de Datos
(software) que a su vez es instalado, configurado, mantenido y optimizado por el Administrador de la
Base de Datos (un ingeniero, analista de sistemas).
Los Sistemas de Bases de Datos tienen éxito en la medida que estén bien diseñados y en la medida que
el Sistema se adapte a las necesidades de la empresa. Por ejemplo, en empresas grandes una Base de
Datos como Access, por poner un ejemplo, no resulta del todo óptimo debido a que se necesita un
sistema más potente que pueda manejar en manera óptima la gran cantidad de operaciones diarias que
estas empresas requieren. Pero además, en el mundo actual, los sistemas han tendido con el tiempo a
ser multiplataforma, y Access no lo es. En el caso de la Base de Datos Oracle o DB2, son sistemas
potentes así como SQL Server pero todos ellos requieren el uso de licencias pagas mayormente. Entonces
el tema de los costos es importante a la hora de tomar decisiones. En general los costos aumentan a
medida que el sistema de Base de Datos es más potente; sin embargo tanto Oracle como DB2 hace años
que sus sistemas son multiplataforma y más recientemente SQL Server. En general considerar los costos
es importante porque no sólo hay que tener el cuenta el costo de implementar el sistema, que tiene que
ver con la compra del mismo y su puesta en funcionamiento, sino su mantenimiento a lo largo del
tiempo.
Un aspecto fundamental para conseguir concomitantemente los objetivos de utilidad, rapidez, seguridad e
integridad de los datos es mediante un buen diseño lógico mediante la normalización de las tablas.

Figura 2
CLASIFICACIÓN
Podemos hacer una clasificación de Sistemas de Bases de Datos teniendo en cuenta su concepción
intrínseca; de esta forma podemos decir que existen los tres tipos vistos en la primera imagen:
 RDBMS: Sistema Administrador de Bases de Datos Relacional o Bases de Datos Relacionales;
 ORDBMS: Sistema Administrador de Bases de Datos Objeto Relacional o Bases de Datos Objeto
Relacionales;
 OODBMS: Sistema Administrador de Bases de Datos Orientados a Objeto o Bases de Datos
Orientadas a Objeto.
Los sistemas de bases de datos que actualmente
existen son los Relaciones u Objeto Relacionales, ya
que los orientados a objeto no han tenido éxito. Así
tenemos a DB2 (de IBM), Oracle, MySQL, Postgress,
SQL Server, Access, etc.
Están basados en la lógica del álgebra relacional y
por lo tanto, cualquier diseño físico corresponderá a
un previo diseño lógico que deberá ser consistente
con su sustento teórico. Para ello es necesario que
se cumplan ciertos requisitos:
Figura 3
1. El diseño lógico es siempre independiente del tipo de aplicación, esto quiere decir que no interesa
si la base de datos es operacional (basada en transacciones) o es para el apoyo a la toma de
decisiones. Inclusive no debería haber mayores discrepancias entre un sistema comercial u otro y
ente un sistema de software libre y uno con licencia.
2. Las tablas que forman la Base de Datos deben estar normalizadas ya que es el requisito
necesario para que puedan aplicarse las operaciones relacionales.
3. Como consecuencia de ello deben poder establecerse reglas de integridad. Por integridad debe
entenderse no sólo mantener la consistencia de los datos (el pegamento, si se quiere entre las
tablas que son las relaciones que vinculan unas tablas con otras), sino también definir el
significado de las tablas y de la base de datos en su totalidad.
La importancia del modelo lógico es tal, que los cambios en el sistema físico deberían siempre amoldarse
a éste. En realidad el modelo físico puede cambiar (el modelo físico implica ya considerar cuestiones

físicas relativas al DBMS que utilizaremos así como el hardware necesario para implementar el sistema)
sin cambiarse el modelo lógico cuando cuestiones de almacenamiento y eficiencia así lo indiquen.
Otra clasificación tiene en cuenta el uso del Sistema de Bases de Datos:
 Sistemas Operacionales o Transaccionales
 Sistemas para el apoyo a la toma de decisiones.
Los Sistemas de Bases de Datos Operacionales o Transaccionales son aquellos que sirven de base
para llevar las operaciones diarias de las empresas y organizaciones. En cambio los Sistemas de Apoyo
a la Toma de Decisiones son sistemas que ayudan en el análisis de información de negocios.
Las bases de datos para la toma de decisiones tienen ciertas características propias. En general puede
decirse que son prácticamente de sólo lectura. Cada tanto se hacen actualizaciones pero que consisten
básicamente en INSERTs (casi nunca DELETEs y menos aún UPDATEs). Esto se debe a que se basan e las
bases de datos operacionales que cada tanto son almacenadas en un repositorio para no perder la
información histórica. Además suelen ser bases de datos grandes.
Figura 4
Los sistemas operacionales en cambio suelen ser bases de datos no tan grandes puesto que las
cuestiones relativas al rendimiento son fundamentales, las cargas de datos (que involucran INSERTs,
UPDATEs y DELETEs o altas, bajas y modificaciones) son generalmente predecibles y de gran volumen, de
allí la importancia de que no estén sobrecargadas con datos de ejercicios anteriores; motivo por el cual
suele contener sólo los datos del ejercicio actual. Los datos de ejercicios anteriores suelen enviarse a un
repositorio, que es en definitiva otra base de datos, generalmente llamada DATA WAREHOUSE. Esta gran
base de datos no sólo suele nutrirse de los datos históricos de la organización sino también de fuentes de
datos externos. De esta manera, estos datos, son procesados y utilizados en los niveles intermedios y
superiores de la organización para la toma de decisiones.
Así para los Sistemas de Apoyo a la Toma de Decisiones tenemos bases de datos especiales como son los
Data Warehouse, los Data Marts, etc.
Un Data Warehouse es un gran almacén de datos integrado y no volátil (quiere decir que una vez
insertados los datos no pueden ser cambiados aunque sí borrados). En su momento surgió para prestar
información específica sobre un tema teniendo una fuente única de información y para no afectar a la
base de datos operacional.

En general un Data Warehouse está pensado para proporcionar una fuente de datos única a todas las
actividades de apoyo a la toma de decisiones, se puede decir que es el corazón central de lo que se
conoce como Inteligencia de Negocios (Business Inteligence). En cambio, los Data Marts consideran un
subconjunto, es decir son almacenes de datos especializados orientados a un tema, integrado, no volátil
pero para apoyar a un subconjunto específico de decisiones de administración.
Asimismo cuentan con un Nivel Analítico que permite sacar conclusiones para la toma de decisiones.
También vale la pena aclarar que antes de cargar los datos al Data Warehouse los mismos son tratados y
procesados.
En resumen un Sistema BI (Sistema de Inteligencia de Negocio) está conformado de la siguiente
manera:
Los Sistemas BI permiten capturar datos de los sistemas de nivel operativo (OLTP, ERP, externos;
sistemas que llevan a cabo decisiones repetitivas y rutinarias) para construir un repositorio de datos
llamado Data Warehouse. Este almacén puede estar formado por diferentes Data Marts o almacenes de
datos para distintos temas específicos. Las distintas metodologías de análisis de datos (OLAP, Minería de
datos, etc.) brindan a los usuarios finales la información necesaria que requieren para la toma de
decisiones no estructuradas.
DISEÑO LÓGICO Y NORMALIZACIÓN - Repaso de conceptos fundamentales
Diseño Lógico o Conceptual de una Base de Datos
El diseño conceptual tiende a identificar las entidades y relaciones existentes, a aplicar las reglas de
normalización, con nombres inequívocos para los atributos de las entidades y finalmente establecer las
reglas de integridad.
Conceptualmente la Base de Datos se diseña inicialmente con lo que se conoce como DER (Diagrama de
Entidad-Relación) y que luego se transforma en un MER (Modelo de Entidad-Relación) junto con un
Diccionario de Datos Elemental (se especifica en el modelo el detalle conceptual de las entidades y
relaciones; es decir cuál es su función u objetivo; los elementos de datos o atributos necesarios y las
reglas de integridad básicas para la base de datos).
Además, hay que tener en cuenta, que al normalizar el diseño, necesariamente las relaciones van a
establecerse por medio de tablas y vínculos entre éstas.
Es muy importante no olvidar que el diseño lógico o conceptual de una Base de Datos debe ser
independiente del diseño físico. Es decir, el diseño lógico debería poder aplicarse para cualquier DBMS
(Oracle, DB2, MySQL, SQL Server, Access, etc.) sin alteraciones en su lógica, mientras que el diseño
físico; es decir cómo se va a implementar este diseño lógico con un DBMS particular y un hardware en
particular, puede ser distinto según las funcionalidades de cada DBMS y de las restricciones
presupuestarias de la organización. Pero incluso el diseño físico puede variar en el tiempo en una misma
organización dependiendo de factores como acceso a la base de datos, costo de mantenimiento,
velocidad de accesos, cambio de hardawre, etc. Por ejemplo la base de datos podría estar alojada en tres
servidores distintos dependiendo de la performance que se necesite, pero el diseño lógico debería seguir
siendo el mismo.
Normalización
Las tablas que forman la Base de Datos deben estar normalizadas ya que es el requisito necesario para
que pueda aplicarse el álgebra relacional y sus operaciones.
La normalización consiste en establecer lo que se conoce como reglas de integridad. De esta forma se
pueden aplicar las operaciones relacionales obteniendo los resultados que prevé el álgebra relacional y no
cualquier otro. Algunas operaciones relacionales se efectúan sobre una misma tabla y otras sobre un
conjunto. Por ejemplo, sobre una misma tabla: seleccionar, proyectar , restringir; sobre conjuntos (sobre
más de una tabla): unión, intersección y diferencia entre conjuntos. En SQL a estas operaciones se las
halla definidas en lo que se conoce como DML o Lenguaje de Manipulación de Datos.
Por integridad debería entenderse que no sólo implica mantener la consistencia de los datos
(el pegamento, si se quiere entre las tablas), sino también definir el significado de las tablas y
de la base de datos en su totalidad; es decir su diseño lógico. En SQL estas definiciones están
representadas por lo que se conoce como DDL o Lenguaje de Definición de Datos y permite crear las
tablas con sus atributos, tipos de datos y restricciones de integridad.
Con las tres primeras formas normales se alcanzarían estos objetivos. Estas tres formas normales fueron
propuestas por Edgard Frank Codd y se basan el cálculo relacional.

Aquí debemos aclarar cuál es la correspondencia entre la terminología relacional y la utilizada en los
distintos sistemas reales ya que no es la misma:
1. Relación = tabla
2. Tupla = fila o registro
3. Atributo = columna o campo
4. Clave = llave o código de identificación
5. Clave Primaria = es la superclave. [PRIMARY KEY en SQL]
6. Clave Ajena = es una clave externa o clave foránea [FOREIGN KEY en SQL]
Primera forma Normal (1FN): siguiendo a J.C. Date, una tabla está en primera forma normal sí y sólo si
es isomorfa a alguna relación. Lo cual significa que la tabla debe cumplir los siguientes requisitos:
 No hay orden de arriba-a-abajo en las filas.
 No hay orden de izquierda-a-derecha en las columnas.
 No hay filas duplicadas.
 Cada intersección de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada
más).
 Todas las columnas son regulares [es decir, las filas no tienen componentes como IDs de fila, IDs
de objeto, o timestamps ocultos].
Cabe hacer las siguientes aclaraciones:
 una tabla no estaría en 1ª Forma Normal si no tiene una clave primaria puesto que así no se
podría asegurar que no aparecieran filas o tuplas duplicadas.
 en el punto 4 existen discrepancias entre distintos autores. Date considera que no se cumpliría la
1FN si se admiten los nulos (debe entenderse por nulo al campo vacío). Otros autores consideran
que mientras la columna no sea una clave se pueden admitir nulos, salvo en la clave primaria.
 el punto 5 significa que una columna no puede tener múltiples valores porque cada valor que
tome un atributo debe ser un dato atómico; es decir, a cada valor de X en la relación le pertenece
un valor de Y, entonces a cada valor de Y le pertenece un valor de X. Por eso mismo Date aclara
que no se permiten los IDs de objetos, filas, etc puesto que estos IDs son en realidad punteros a
otra tabla; con lo cual no se respeta la atomicidad.
 respecto a las claves conviene aclarar lo siguiente:
1. Una clave primaria es aquella columna (pueden ser también dos columnas o más) que
identifica únicamente a esa fila. La clave primaria es un identificador, y por lo tanto, los
valores que debe tomar deben ser únicos para cada fila y no se admite el valor nulo. Es una
costumbre colocar como primera columna a la clave primaria, pero ello no es necesario.
Además muchos RDBMS suelen permitir la opción de declarar a esta clave como
autonumérica.
2. Una clave foránea es aquella
columna que existiendo como
dependiente en una tabla, es a su
vez clave primaria en otra tabla;
es decir, que es lo que vincula a
ambas tablas.
3. Asimismo una clave es compuesta
cuando está formada por más de una
columna.
Segunda forma Normal (2FN): Una relación está
en 2FN si está en 1FN y si los atributos que no
forman parte de ninguna clave dependen de
forma completa de la clave principal.
Figura 5

El siguiente es un ejemplo tomado del libro
del autor citado. La tabla PRIMERA contiene
información de los proveedores (V) y las
partes que los proveedores han enviado (P).
Esta tabla está en 1FN ya que no se repiten
las filas siendo su clave primaria compuesta
(V#,P#)Pero PRIMERA No está en 2FN
porque el campo Status no depende de la
clave primaria sino de la ciudad y la ciudad
sólo depende de la columna proveedor (V)
pero no de la clave primaria. Esta situación
trae consecuencias nefastas con las
operaciones INSERT, UPDATE Y DELETE. ¿Por
qué? Simplemente si consideramos la
operación DELETE para el proveedor 3 (V3)
eliminaremos también la información relativa sobre la parte que envío (P2). Esta situación se soluciona
reduciendo PRIMERA a dos tablas que estén en 2FN: las tablas SEGUNDA y VP.
La clave primaria de SEGUNDA es V# y de la nueva tabla VP es una clave primaria compuesta como
antes y formada por el par de columnas (V#,p#).
En resumen: ahora tenemos dos tablas en lugar de solo una: SEGUNDA y VP
Tercera forma Normal (3FN): Una relación se encuentra en 3FN si está en 2FN y cada atributo que no
forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.
La tabla SEGUNDA está en 2FN pero no está en 3FN. Esto se debe a que la Ciudad depende del proveedor
(V) pero el E stado (Status) depende de la Ciudad, con lo cual se da una relación transitiva y por eso es
que no se cumple con la 3FN
En cuanto a la tabla VP, la misma está
en 2FN y también cumple con la 3FNya
que la cantidad depende directamente
de la clave primaria que identifica a un
envío en particular (recordemos que es
una clave primaria compuesta).
Al normalizar la tabla SEGUNDA nos
quedan dos tablas nuevas: la tabla VC
que relaciona los proveedores con la
ciudad en la que se encuentran y la
tabla CS que relaciona el estado para cada ciudad, lo que puede apreciarse en la Figura 6.
Por lo tanto, el modelo ha quedado reducido a tres tablas: VP, VC Y CS. Puede apreciarse a simple vista
que para VP la clave primaria es (V#,P#). La tabla VC tiene a V# como clave primaria y la tabla CS tiene
a CIUDAD como clave primaria.
Asimismo VP tiene una clave primaria (V#,p#) y dos claves foráneas: V# y P#. V# hace referencia a la
tabla VC en la cual V# es primaria y la clave P# hace referencia a tabla P de partes, que aparece en los
diagramas pero cuya clave primaria es P#. La tabla VC tiene como clave foránea a CIUDAD que se
vincula con la tabla CS donde la clave primaria es CIUDAD.
DISEÑO FÍSICO Y LÓGICO DE UNA BASE DE DATOS. Diferencias. Casos Prácticos
El diseño lógico de un sistema de base de datos es más bien permanente en el tiempo, en cambio el
diseño físico es variable ya que debe considerar no sólo el hardware sobre el que se va a instalar, sino
también cambia según el DBMS que consideremos utilizar. Por ejemplo Oracle, DB2, SQL Server (edición
Empresarial) y MySQL permiten el particionamiento de tablas, la fragmentación de tablas y la replicación,
aunque depende de la versión a utilizar.
Además los sistemas más modernos y potentes permiten crear sistemas de bases de datos distribuidos,
que es lo que más se utiliza hoy en día juntamente con la computación en la nube. Estos sistemas son
distintos entre sí y también existe gran cantidad de software intermedio, conocido como Middleware, que
permite que se puedan compartir datos e información de distintos sistemas de bases de datos y corriendo
sobre diferentes sistemas operativos, cuando el sistema es distribuido. Es decir que podríamos encontrar
parte del sistema de bases de datos con un DBMS de DB2, en otro ORACLE, otro con SQL Server, etc.
Figura 6
Figura 7

Caso práctico: Diseño Lógico BD Escuela
El diseño lógico, como sabemos, debe poder dar una respuesta al modelo de datos que maneja la
organización.
Es por esto que el diseño lógico es independiente del diseño físico de la base de datos y suele
mantenerse a lo largo de los años inalterable puesto que, en general, responde al objeto o meta a la cual
está dirigido todo el accionar de la organización.
Para trabajar en clase vamos a utilizar un modelo de datos de una Escuela como ejemplo didáctico
de modo tal que sea fácil de entender y de llevar a la práctica.
En la Figura 7 puede apreciarse el Modelo de Entidad – Relación de la Base de Datos Escuela. El
mismo es consecuencia de la normalización de datos y de la expresión del diseño del diccionario de
datos, el cual se muestra en la Figura 8, y que además está disponible para su descarga en el Sitio
Web de la materia.
En el MER pueden apreciarse, en forma gráfica, tanto las claves primarias y las foráneas, indicadas
mediante la relaciones; en el diccionario también se expresan las relaciones existentes pero en forma
narrativa, y se especifican los requisitos de los diferentes atributos de las tablas.
Todas las claves primarias son simples, salvo la de la tabla Notas que es una clave primaria
compuesta; es decir y se indica de esta forma: Clave primaria = (Idmateria, DNI).
En la tabla Materias su clave primaria es Idmateria, y no tiene foráneas.
La clave primaria de la tabla Alumnos es DNI y tiene como foránea al atributo Idlocalidad. Nótese que
en la tabla Localidades Idlocalidad es una clave primaria.
En general, puede decirse que toda clave foránea referencia o se vincula con una clave
primaria, o por lo menos una clave única, de por lo general otra tabla (aunque podría ser un
atributo de la misma tabla).
Finalmente la tabla Notas tiene una clave primaria que es compuesta ya que está formada por dos
atributos: Idmateria y DNI. La notación para indicar que una clave es compuesta es así:
(idmateria,DNI), SIEMPRE entre paréntesis y separados los atributos por comas.
Pero si se lee en forma correcta el MER se notará que la tabla Notas es una tabla que tiene dos
relaciones de 1 a muchos: una con la tabla Alumnos y la otra con la tabla Materias. Esto quiere decir,
que cada atributo, por separado, es por sí una clave foránea; además de que ambos atributos en
forma conjunta forman la clave foránea.
Es así que Idmateria es una clave foránea que referencia a la clave primaria de la tabla Materias, y
DNI es la otra clave foránea de la tabla Notas que referencia a la clave primaria de la tabla Alumnos.
Leer bien el MER significa comprender que todas las claves foráneas están indicadas por las relaciones
uno a muchos. Esto es la lógica que une todas las entidades o tablas y las mantiene como una unidad,
que en definitiva es lo que se llama base de datos relacional.
El diseño de las claves primarias y foráneas es una consecuencia de la normalización y es fundamental
para lograr la integridad de los datos. Es más es fundamental en todo el proceso el aplicar las
buenas prácticas y la metodología en cuanto al diseño y desarrollo de software. Es así, que
se puede notar que tanto los nombres de las tablas como sus atributos tienen una nomenclatura fácil
de reconocer y que además el diseño tiene en cuenta los cambios entre mayúsculas y minúsculas.
Este es un tema de suma importancia ya que el software primero se diseña y luego se programa,
pero siempre es necesario poder llevar a cabo actualizaciones y/o mejoras, que implican mantenerlo
en el tipo. Por ende, es importante que no perdamos de vista este aspecto, ya que tener control sobre
lo que se diseña y luego se implementa permite desarrollar software independiente de la plataforma,
es decir, software multiplataforma.
Si le damos un simple vistazo al Diccionario de datos Lógico, de entrada vemos que nos dice más que
el MER sobre los requisitos de los atributos, motivo por el cual es fundamental tenerlo en cuenta para
poder llegar a un buen diseño físico, que siempre va a depender de la tecnología (hardware) y del
DBMS que elijamos.
En el diseño lógico, a través del diccionario, establecemos claramente, para cada atributo si: es clave
primaria (PK), si es clave foránea (FK), si es un atributo obligatorio y, lo más importante, establecemos el
DOMINIO del atributo (si va a ser numérico, lógico, cadena o fecha) PERO NO SU TIPO DE DATOS.
Esto es sumamente importante tenerlo claro, el tipo de datos es siempre dependiente del modelo físico y
es un concepto por ende concreto más limitado que el dominio; es decir, del DBMS que vayamos a
utilizar para plasmar en la realidad el diseño lógico tendrá diferentes tipos de datos para un dominio

numérico, por ejemplo, MySQL tiene varios tipos de datos enteros: int, biging, smallint, etc.; y lo mismo
ocurre con otros DBMS. A lo sumo, en el Diccionario de Datos Lógico podemos mencionar que el
dominio Numérico es corto o largo, por ejemplo, un número de CUIT o CUIL, si consideramos que
pertenece al dominio numérico, al tener 11 dígitios, difícilmente sea un entero común sino más bien un
entero largo, en casi cualquier sistema de bases datos.
Finalmente, por cuestiones de documentación, también es muy importante describir cuál es el fin del
atributo, si tiene restricciones por ejemplo un atributo entero no debería tomar valores superiores a 99 ni
inferiores a 1; etc.
Figura 8: MER para la BD Escuela
Figura 9: diseño lógico – diccionario de datos de la BD Escuela

Caso Práctico: Diseño Físico BD Escuela
Como ya hemos expresado, el diseño físico es la implementación en un DBMS de la vida real del
diseño lógico ya realizado.
En la Figura 10 presentamos el diseño físico para MySQL. Hay que recordar que el diseño físico
siempre surge del (tanto el MER como el diseño lógico del diccionario), ya que el diseño lógico es
único e independiente del diseño físico, y por ende, del DBMS que vayamos a utilizar.
En la Figura 11 presentamos el diseño físico para SQL Server, por una curiosidad puesto que hoy en
día la materia ya no se desarrolla en base a este DBMS, ya desde 2014.
Volviendo a la Figura 9, con el Diseño Físico, cabe aclarar que ya no hablamos de dominio de un
atributo (los valores y tipos de datos que puede tener) sino que especificamos el tipo de datos
que mejor se ajusta a ese dominio y el tipo de datos específico del DBMS elegido (es decir
cómo se llama en la realidad).
También es importante nombrar en forma explícita cómo se llamarán todas las claves primarias así
como las claves foráneas ya que, de no hacerlo, el DBMS, cualquiera que elijamos, le asignará un
nombre por omisión.
Otro aspecto sumamente importante es verificar la documentación de cada DBMS y su versión puesto
que los tipos de datos pueden variar entre DBMS pero también entre diferentes versiones del mismo
DBMS, como veremos más adelante, el diseño físico puede cambiar no sólo por cuestiones
presupuestarias o tecnológicas referidas a avances propios de la tecnología o como consecuencia de la
expansión de una empresa pero también pueden surgir de un análisis más profundo sobre los tipos de
datos, sus limitaciones así como las limitaciones que también tiene el software de programación que
utilicemos, cuestiones éstas que serán ampliadas en la segunda parte.
Diseño Físico para MySQL
Figura 10: Diccionario de datos físico para MySQL

Diseño Físico para SQL Server
Figura 11: Diccionario de datos físico para SQL Server (Express Edition 2012 y
utilizado en los ciclos lectivos 2013 y 2014)

POOABD (POO Aplicada a B Datos) - RDBMS parte 1 -2020

Más contenido relacionado

La actualidad más candente

Similar a POOABD (POO Aplicada a B Datos) - RDBMS parte 1 -2020

Más de Laura Noussan Lettry

Último

POOABD (POO Aplicada a B Datos) - RDBMS parte 1 -2020