POOABD (POO Aplicada a B Datos) - RDBMS parte 2 -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 2
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 2
Introducción
1. SQL (Lenguaje de Consultas Estructurado). Concepto y Sintaxis. Tipos de
Lenguaje SQL: DML y DDL.
2. SQL – DDL: Sentencias CREATE, ALTER, RENAME y DROP aplicadas a Tablas
y Vistas.
Sentencia INSERT, Sentencia UPDATE y Sentencia DELETE.
3. SQL – DML: Sentencia SELECT: básica, con proyección, con restricción y mixta;
distintos casos sobre una tabla o más tablas. Utilización de cláusulas para
ordenamiento y agrupamiento.
4. Caso práctico: ajustando el diseño físico de la BD Escuela. Aplicación práctica
de tipos de Datos, ALTER TABLE, RENAME, DROP, etc.
2
3
4
24
34
FUENTES Bibliográficas Consultadas
1. Ayuda en línea de MySQL Community Edition y línea de comandos
BIBLIOGRAFÍA para el Alumno
1. Contenidos del presente apunte
2. NOUSSAN LETTRY, Laura y otros, Secuencia Didáctica de Comandos SQL -
Ejemplos y Resultados (Cátedra de Gestión de Datos, 3o Año, Ingeniería en
Sistemas de Información UTN – FRM) (*)
3. NOUSSAN LETTRY, Laura, Conexiones JDBC con MySQL y SQL Server
(Mendoza, 2013) (*)
4. BrowserSQL versión 4 y su Tutorial (*)
5. MySQL Community Edition y línea de comandos de MySQL
6. https://www.w3schools.com/sql/default.asp
ACTIVIDADES
Puntos 1/3 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 2
INTRODUCCIÓN
Ahora, que ya hemos encarado el mundo de los Sistemas de Bases de Datos
Relacionales desde un sustento teórico práctico, lo que haremos es seguir los pasos
necesarios para crear un Sistema de Bases de Datos relacional físico.
Para ello utilizaremos uno de los DBMS que hoy en día es ampliamente utilizado
actualmente son muy utilizados:
MySQL en su versión Community Edition
Aprenderán también que en el mundo real no siempre se siguen los estándares y que
además el software, como casi todo en la vida, ambos tienen sus ventajas y desventajas;
lo que es cierto también para otros RDBMS como son Oracle o DB2.
Una diferencia básica entre ambos es que MySQL es multiplataforma; es decir puede
correr sobre Sistemas Operativos basados en Windows como en Sistemas Operativos
basados en Linux, motivo por el cual, y por ser de distribución gratuita, bajo determinadas
circunstancias, es el RDBMS más utilizado en la Web.
La versión SQL Server corre sobre Sistemas Operativos Windows y la versión Express si
bien es de distribución gratuita no es multiplataforma.
Para poder utilizar SQL en forma independiente del DBMS, de modo tal que nos sirva
para fines didácticos, utilizaremos un software que hemos desarrollado en Java:
BrowserSQL versión 4.
Dicho software permite conectarse a MySQL y SQL Server y está disponible para su
descarga en forma gratuita juntamente con su tutorial desde nuestro sitio web

SISTEMAS DE BASES DE DATOS RELACIONALES
1- SQL (Lenguaje de Consultas Estructurado)
SQL. Concepto
SQL es un lenguaje de alto nivel creado para el tratamiento de datos almacenados en bases de datos
relacionales.
Es un lenguaje de tipo declarativo; es decir, no es procedural o imperativo, y permite trabajar con
datos a nivel de conjunto, a diferencia de los lenguajes imperativos que trabajan en torno al registro
individual y que requieren de lógica procedural para el tratamiento de los datos.
Está basado en álgebra relacional y cálculo relacional orientado a tuplas.
Sus instrucciones básicas se pueden dividir en dos grupos:
1. DDL (Data Definition Language): conjunto de instrucciones que permiten definir tablas,
índices, etc.
2. DML (Data Manipulation Language): se utilizan para actualizar información en la base de datos
(insertar, eliminar o modificar filas en tablas) y para extraer información de la misma mediante
consultas.
Además de estos grupos existen otros, cuyas instrucciones permiten realizar otras operaciones
aplicadas al DBMS y/o a sus bases de datos, siendo uno de los más importantes la creación de
usuarios, sus roles y niveles de seguridad; que por su complejidad y extensión, exceden el desarrollo
de la materia.
Sintaxis SQL
Toda la definición de la sintaxis y uso de SQL está incluida en estándares que van actualizándose
periódicamente. Actualmente el último estándar publicado por la ISO es de 2016
(https://www.iso.org/advanced-search/x/) puesto que debido a los avances tecnológicos se sigue
trabajando en el lenguaje, inclusive en los OODBMS, por lo tanto no todos los papers y estándares se
refieren a RDBMS.
Muchos de los RDBMSs del mercado satisfacen gran parte de estándares anteriores (SQL/92, SQL/99) y
otros este último estándar. Pero además, varios de los RDBMSs líderes en el mercado tales como DB2 de
IBM, ORACLE, SQL Server de Microsoft y otros, ya con los anteriores estándares, como el de 2013 y
previos, tenían funcionalidades que van más allá de los estándares y, en base a estas funcionalidades,
muchas veces se elaboran nuevos estándares.
Para encarar el estudio de la sintaxis SQL se utilizará el material disponible en la bibliografía y que puede
descargarse desde el sitio web: Secuencia Didáctica
Tipos de Lenguajes SQL: DML y DDL
Como ya vimos, SQL se divide en dos grandes grupos de sentencias: SQL-DDL y SQL-DML, pero no
son las únicas, existen otras, que no veremos aquí.
Ahora ¿qué sentencias están incluidas en SQL-DDL y cuáles en SQL-DML?
LENGUAJE SQL SENTENCIAS OBJETOS
SQL-DDL
CREATE
ALTER
RENAME
DROP
Tablas, vistas e índices
SQL-DML
SELECT (en cualquiera
de sus formas)
Tablas y vistas
INSERT
UPDATE
DELETE
Tablas, vistas e índices

2. SQL – DDL: Sentencias CREATE, ALTER, DROP y RENAME
Las sentencias que vamos a ver son: CREATE, ALTER, DROP y RENAME
El ejemplo está basado en el diseño lógico y físico para la BD Escuela. Los mismos se han llevado a
cabo utilizando MySQL con el BrowserSQL mayoritariamente, aunque también hay algunos ejemplos
de cómo utilizar la consola de comandos de MySQL en forma directa.
La Sintaxis para las diferentes sentencias SQL están remarcadas en rectángulos rojos.
Sentencia CREATE
Esta sentencia nos permite crear la misma base de datos, crear tablas, vistas, etc. En los ejemplos
veremos la creación de la Base de Datos Escuela.
CREACIÓN DE LA BASE DE DATOS
CREATE nombreBD
CREACIÓN DE TABLAS
La sentencia tiene esta sintaxis:
CREATE nombreTabla (
atributo1 [NOT NULL][DEFAULT],
atributo2 [NOT NULL][DEFAULT],
… atributoN [NOT NULL][DEFAULT],
CONSTRAINT nombrePK PRIMARY KEY(atributoPK),
[CONSTRAINT nombreFK FOREIGN KEY(atributoFK) REFERENCES nombreTablaR
(atributoPK_tablaR)])
El presente ejemplo utiliza la tabla Materias, ya que junto con Localidades, en base al diseño lógico y
físico de la BD Escuela, sabemos que son dos tablas primarias, que son las que primero deberemos
crear.
El diseño lógico me indica que la tabla Materias debe tener dos atributos por lo menos:
 Idmateria: que es un dato que pertenece al dominio numérico que además va a ser la
clave primaria de la tabla.
 nom_materia: que va a representar el nombre de la materia, siendo el dominio de datos
alfanumérico.
El diseño físico:
 Idmateria: el tipo de datos para MySQL elegido es un entero que se denomina INT.
Además como va a ser la clave primara también se establece el nombre de la misma
PK_MATERIA.
 nom_materia: el tipo de datos para MySQL elegido es una cadena alfanumérica de una
longitud máxima de 40 caracteres que se denomina VARCHAR(40).
La sentencia SQL 
CREATE TABLE Materias(Idmateria INT NOT NULL, nom_materia VARCHAR(40) NOT
NULL, CONSTRAINT PK_MATERIA PRIMARY KEY(Idmateria))
Las siguientes imágenes muestran la sentencia CREATE:

Hemos creado la BD Escuela (más precisamente Escuela2 porque ya la tenemos creada en nuestra PC).
 Lo primero es seleccionar el controlador JDBC que implica elegir el sistema de bases de datos, en
nuestro caso MySQL.
 Lo segundo es ingresar la cadena de conexión, en este caso, porque vamos a crear una base de
datos debemos conectarnos a la Instancia principal: jdbc:mysq://localhost:3306/
 Luego es necesario ingresar el usuario y la contraseña para finalmente presionar el botón
Conectar.
Si la sentencia fue exitosa aparecerá un mensaje de éxito como el mostrado en la imagen.
Si queremos crear las tablas en la BD Escuela, es preciso desconectarse (lo que muestra la imagen) y
volverse a conectar al sistema, pero utilizando el link a la base de datos misma y no a la instancia
principal,para lo cual es preciso escribir: jdbc:mysql://localhost:330/Escuela2, que se muestra en la
siguiente imagen

Hemos escrito la sentencia y el mensaje nos dice que fue exitosa.
Estos mensajes tienen en cuenta el código de éxito o error que el mismo DBMS envía a la aplicación
BrowserSQL. Ya se trate de un mensaje de éxito o fracaso al utilizar sentencias SQL, siempre las escribe
en el área de mensajes (área gris). Esto nos permite copiar las sentencias exitosas (en el orden correcto
de creación de las tablas) y crear un script de backup, no sólo para poder recrear la base de datos sino
que el mismo procedimiento se puede seguir para hacer un backup de las inserciones, por ejemplo.
El mensaje de éxito, replicando la sentencia ejecutada se puede apreciar en la siguienteimagen:

El ejemplo se basó en la creación de una Tabla que es primaria, es decir, no cuenta con claves
foráneas. El siguiente ejemplo muestra cómo crear la tabla Notas, que por ser la tabla más derivada o
más dependiente (tiene 2 claves foráneas) es la última que debemos crear. Además en el ejemplo
utilizaremos la palabra reservada DEFAULT para el atributo aprobado.
Por el diseño lógico y físico sabemos que la tabla Notas tiene una clave primaria compuesta
(Idmateria, DNI) y dos claves foráneas que referencian una de ellas a la tabla Alumnos (DNI) y la otra
a la tabla Materias(Idmateria).
La sentencia SQL 
CREATE TABLE Notas(Idmateria INT NOT NULL, DNI INT NOT NULL, parcial_1 DECIMAL(4,2), parcial_2
DECIMAL(4,2),aprobado TINYINT DEFAULT 0,
CONSTRAINT PK_NOTAS PRIMARY KEY(Idmateria,DNI),
CONSTRAINT FK_MATERIA FOREIGN KEY(Idmateria) REFERENCES Materias(Idmateria),
CONSTRAINT FK_ALUMNO FOREIGN KEY (DNI) REFERENCES Alumnos(dni))
Importante:
 La clave primaria compuesta se indica en el CONSTRAINT entre paréntesis todas las columnas o
atributos que forman la clave primaria, en este caso son sólo dos: (Idmateria, DNI)
 En el caso del DEFAULT, significa que como la columna no es obligatoria, si el usuario no ingresa
un valor o si no se pasa el valor en un INSERT entonces el atributo no quedará como nulo sino
con el valor igual a cero, ya que en MySQL TINYINT===BIT===BOOLEAN, por ende el atributo
sólo puede valer 1 ó 0, el problema es que al no hacerlo NO NULO puede quedar inconsistente.
 En el caso de las parciales, hemos optado por dejarlo con valores nulos pero se podría haber
utilizado también la palabra reservada DEFAULT
 En las claves de esta tabla hemos usado los mismos nombres de atributos que hemos usado en
las tablas primarias: DNI e Idmateria pero podrían haberse usado otros nombres, aunque esto le
restaría claridad, así además está diseñado y finalmente lo importante es que sí tienen que
coincidir siempre los tipos de datos entre la clave foránea que referencia a una primaria.
Por todo esto es fundamental partir de un buen diseño y basarse en éste, tanto el
lógico como el físico (de hecho el físico depende del lógico). Un buen diseño se basa
en las buenas prácticas de diseño y programación, más aún hoy en día que la
programación está orientada a ser multiplataforma. Por ende deben respetarse los
nombres asignados a las tablas y sus atributos, respetando mayúsculas, minúsculas,
no utilizar nombres que no se entiendan (es como lo que aprenden en tercer año
respecto a los nombres de variables, deben ser representativos) ni caracteres
especiales, por ejemplo el espacio en blanco es un carácter especial, y lógicamente
no sólo se trata de codificar o diseñar, siempre hay que documentar.

A continuación las imágenes de creación de la tabla utilizando el BrowserSQL:
Para ejemplificar qué pasa cuando ingresamos mal una sentencia:
El mensaje proviene directamente del DBMS, por eso está en inglés y nos dice que hay un problema en el
primer constraint. El error se debe a que en lugar de escribir FOREIGN escribimos FOREIGH.
Se acepta el error y entonces el error se graba también en la zona de mensajes pero podemos arreglarlo
escribiendo bien la sentencia y luego clickear el botón Ejecutar:
Sentencia ALTER
Sirve para modificar la estructura de un objeto, por ejemplo, una tabla. Entre los diferentes DBMS
suele haber bastante diferencia en la sintaxis de esta sentencia. En resumen para esta sentencia hay
que ir a la ayuda del DBMS que estemos usando y a la versión correcta par no encontrarnos con
problemas.
La sentencia es bastante complicada de por sí, pero es más fácil de implementar cuando de lo que se
trata es de crear por ejemplo un atributo nuevo o una nueva clave. No así cuando se trata de
modificar la estructura de un atributo ya existente y menos si se trata de claves vinculadas, es decir
de foráneas y primarias.

Vamos a modificar la tabla Localidades de modo que también tenga otro atributo más: el código postal
nuevo que es un atributo alfanumérico.
A este atributo lo crearemos y lo llamaremos cod_post2 será de tipo alfanumérico con una longitud
máxima de 8 caracteres y no nulo.
Hay que tener en cuenta además si tenemos o no datos insertados en la tabla Localidades para ver
qué sucede.
Como podemos ver MySQL nos permite agregar la columna aunque ya tengo datos insertados en la
tabla, esto se muestra en las siguientes imágenes.
La secuencia que utilizamos fue:
1) aplicamos ALTER TABLE para agregar la columna cod_post2 cuando la tabla no tenía datos
2) aplicamos ALTER TABLE para borrar dicha columna
3) insertamos datos en la tabla Localidades (3 registros)
4) aplicamos nuevamente la sentencia ALTER TABLE utilizada en el paso 1
A continuación se muestran las sentencias y las imágenes respectivas.
1) ALTER TABLE Localidades ADD COLUMN cod_post2 VARCHAR(8) NOT NULL
2) ALTER TABLE Localidades DROP COLUMN cod_post2

3)
INSERT INTO Localidades VALUES(1,'Mendoza',5500)
INSERT INTO Localidades VALUES(2,'Godoy Cruz',5501)
INSERT INTO Localidades VALUES(3,'Lujan de Cuyo',5507)
4) ALTER TABLE Localidades ADD COLUMN cod_post2 VARCHAR(8) NOT NULL
Las siguientes imágenes muestran la información de la tabla utilizando la solapa Metadatos del
BrowserSQL.
Primero seleccionamos el botón Objetos, que mostrará las tablas que tiene la base de datos.
Luego seleccionamos la tabla Localidades en la columna Table Name y clickamos en el botón Columnas
Así obtendremos la información sobre las columnas que tiene la tabla y su tipo de datos.

Si bien el BrowserSQL es muy completo tiene ciertas limitaciones porque utiliza sentencias que son
multiplataforma, sin embargo MySQL tiene diferencias con otros DBMS para ver la estructura de las
tablas. Entonces si necesitamos chequear todo, que esté correcto pues es mejor utilizar la misma base
de datos MySQL mediante la consola de comandos.
Consola de Comandos MySQL en Linux Mint
Para ingresar a la consola de comandos de MySQL debemos iniciar una Terminal (desde el Menú o
desde la barra de tareas se lanza la Terminal Linux)
Una vez abierta como usuario común escribimos:
usuario@maquina > mysql -u root -p
Este comando quiere decir que estamos queriendo ingresar a MySQL utilizando el usuario (-u) root y
que pasaremos una contraseña (-p) [recordar que contraseña es password en inglés]
Escribimos la contraseña: aguila13 y damos enter (según la versión de Linux Mint, el ingreso de la
contraseña puede o no mostrar la longitud de la cadena ingresada)
Las siguientes imágenes muestran la sentencia de ingreso:
Con la sentencia use de MySQL seleccionamos la base de datos, sino estamos en la instancia principal
La sentencia show tables es otra sentencia de MySQL, es decir, específica del DBMS y nos permite ver
las tablas que tiene la base de datos.

Como podemos ver hemos ingresado la sentencia Select de SQL para ver el contenido de la tabla
Localidades.
Importante: todas las sentencias vía consola de MySQL deben terminar en un punto y coma (;)
La siguiente imagen nos muestra el uso de la sentencia describe es otra palabra reservada o sentencia
propia de MySQL y nos permite ver la estructura de la tabla. Básicamente es la misma información que
podemos obtener con la solapa Metadatos del BrowserSQL sólo que además nos dice qué columnas
admiten valores nulas, si tienen valores por defecto y otra información extra que podríamos haber
considerado al crear las tablas.

La consola nos brinda información extra con el comando de MySQL describe ya que nos permite ver
más información, por ejemplo si alguna columna está definida con valor nulo.
Como sabemos sólo la tabla Notas, en base al diseño lógico/físico es la única que iba a tener campos
con valores nulos: los parciales y aprobado (teniendo este un valor por defecto igual a cero)
Sin embargo podemos ver que al crear las tablas hemos cometido algunos errores, que suelen ser
bastante habituales ya que leemos desde el diseño físico y escribimos en el BrowserSQL o también
podríamos haber usado directamente la consola de MySQL, lo que no quiere decir que no se puedan
producir errores por distracción, motivo por el cual siempre hay que testear lo que hemos hecho.
Concretamente tendremos que arreglar las siguientes columnas de las siguientes tablas:
 cod_post en Localidades
 Apellido en Alumnos
 Nombre en Alumnos
Para esto nos sirve también la sentencia ALTER TABLE, de hecho vamos a utilizar la Ayuda de MySQL
que viene instalada con la base de datos vía comando.
Consola de Comandos MySQL - Ayuda
Para encontrar la ayuda sobre las diferentes sentencias del DBMS MySQL basta con ingresar a la
Consola de MyQSL, como ya vimos, y luego escribir help contents; (no olvidar el punto y coma).
De esta forma obtendremos un listado ordenado por categorías, como se muestra en la siguiente
imagen.
Lo que más necesitaremos consultar para la materia son las secciones Data Definition y Data
Manipulation.
Para obtener la ayuda relacionada a las sentencias DDL escribiremos:
help Data Definition;
Al pulsar Enter luego de la sentencia obtendremos el siguiente listado:
ALTER DATABASE
ALTER EVENT
ALTER FUNCTION
ALTER INSTANCE

ALTER LOGFILE GROUP
ALTER PROCEDURE
ALTER SERVER
ALTER TABLE
ALTER TABLESPACE
ALTER VIEW
CONSTRAINT
CREATE DATABASE
CREATE EVENT
CREATE FUNCTION
CREATE INDEX
CREATE LOGFILE GROUP
CREATE PROCEDURE
CREATE SERVER
CREATE TABLE
CREATE TABLESPACE
CREATE TRIGGER
CREATE VIEW
DROP DATABASE
DROP EVENT
DROP FUNCTION
DROP INDEX
DROP PROCEDURE
DROP SERVER
DROP TABLE
DROP TABLESPACE
DROP TRIGGER
DROP VIEW
RENAME TABLE
TRUNCATE TABLE
Como lo que queremos hacer es modificar la estructura de dos tablas: Localidades y Alumnos buscaremos
la ayuda sobre ALTER TABLE, como antes escribiremos help ALTER TABLE;
Importante: en el caso de la ayuda de MySQL cabe destacar que no es sensible a mayúsculas y
minúsculas, motivo por el cual también podremos escribir help alter table;
El comando larga bastante información, de la cual hemos copiado desde la consola y pegado lo
fundamental:
mysql> help alter table;
Name: 'ALTER TABLE'
Description:
Syntax:
ALTER TABLE tbl_name
[alter_specification [, alter_specification] ...]
[partition_options]
alter_specification:
table_options
| ADD [COLUMN] col_name column_definition
[FIRST | AFTER col_name]
| ADD [COLUMN] (col_name column_definition,...)
| ADD {INDEX|KEY} [index_name]
[index_type] (key_part,...) [index_option] ...
| ADD [CONSTRAINT [symbol]] PRIMARY KEY
| ADD [CONSTRAINT [symbol]]
UNIQUE [INDEX|KEY] [index_name]
| ADD FULLTEXT [INDEX|KEY] [index_name]
(key_part,...) [index_option] ...
| ADD SPATIAL [INDEX|KEY] [index_name]
(key_part,...) [index_option] ...

| ADD [CONSTRAINT [symbol]]
FOREIGN KEY [index_name] (col_name,...)
reference_definition
| ALGORITHM [=] {DEFAULT|INPLACE|COPY}
| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
| CHANGE [COLUMN] old_col_name new_col_name column_definition
[FIRST|AFTER col_name]
| [DEFAULT] CHARACTER SET [=] charset_name [COLLATE [=] collation_name]
| CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]
| {DISABLE|ENABLE} KEYS
| {DISCARD|IMPORT} TABLESPACE
| DROP [COLUMN] col_name
| DROP {INDEX|KEY} index_name
| DROP PRIMARY KEY
| DROP FOREIGN KEY fk_symbol
| FORCE
| LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE}
| MODIFY [COLUMN] col_name column_definition
[FIRST | AFTER col_name]
| ORDER BY col_name [, col_name] ...
| RENAME {INDEX|KEY} old_index_name TO new_index_name
| RENAME [TO|AS] new_tbl_name
| {WITHOUT|WITH} VALIDATION
| ADD PARTITION (partition_definition)
…. continúa
Lo que hemos sombreado en amarillo es lo que nos interesa para modificar la columna cod_post de la
tabla Localidades de modo tal que no admita nulos.
En celeste hemos marcado otra opción que se utiliza con MySQL para además de modificar la definición
de la columna, el nombre de la misma.
Vamos a modificar la estructura de la tabla Localidades utilizando la consola de MySQL en lugar de utilizar
el BrowserSQL
La imagen muestra comandos ya utilizados, pero algo más importante: las sentencias SQL o las
sentencias propias de MySQL sí son sensibles a mayúsculas y minúsculas respecto de los objetos.
Los objetos para el DBMS son las tablas, índices, vistas, etc. Por ello la imagen muestra el error cuando en
lugar de utilizar la sentencia describe Localidades; utilizamos describe localidades;
Otro tema importante es que tenemos que estar a nivel de la base de datos para modificar las tablas, o sea
tenemos que usar la sentencia use nombreBaseDatos;

Como podemos apreciar es posible escribir la sentencia en minúscula, pero no el nombre de la tabla, ya
que es un objeto. El comando fue ejecutado con éxito (Query OK) y además lo comprobamos visualmente
al ejecutar el segundo describe sobre la tabla.
Sin cerrar la consola de MySQL vamos a utilizar el BrowserSQL
Lo comprobamos con la consola de MySQL

El primer describe muestra la estructura antes de ejecutar la sentencia vía BrowserSQL y el segundo
después. Nos está quedando el Nombre.
Importante: como el atributo Nombre no es un objeto sino que es un atributo de un objeto, podemos utilizar
minúsculas sin problemas. La imagen nos muestra con el último describe que todos los atributos no
pueden admitir valores nulos.
Supongamos que queremos cambiar el nombre del atributo email a Email
Como se puede ver en la imagen, no basta con cambiar el nombre del atributo sino que además hay que
escribir la definición de los datos de la columna o nos dará un error.

La imagen muestra esta situación y su solución.
Hemos cambiado el tamaño de la terminal para que se vea mejor.
Finalmente revisamos la estructura de la tabla con un comando describe sobre la tabla y vemos que el
atributo o columna ahora se llama Email, lo comprobamos con el BrowserSQL también
Ahora hemos maximizado la consola y ajustado el BrowserSQL.
Las ventanas o terminales de Linux permiten modificar su tamaño en forma fácil, además de copiar y pegar
texto en forma directa con el ratón.

Sentencia RENAME
Permite renombrar un objeto, por ejemplo una tabla, vista, etc.
La sintaxis es
RENAME TABLE nombreTAblaViejo TO nombreTAblaNuevo
Para este ejemplo con RENAME y el siguiente con DROP vamos a usar una tabla diferente,
directamente usaremos Materias2 con los mismos atributos que ya tenemos en el archivo de script a
modo de backup de la implementación de la base de datos.
Sin embargo deberemos ajustar algunas cosas ya que no sólo el nombre de la tabla no se puede
repetir (es un objeto) sino que tampoco se pueden repetir los nombres de las claves foráneas ya que
vinculan a otra tabla.
La sentencia original fue:
CREATE TABLE Materias(Idmateria INT NOT NULL, nom_materia VARCHAR(40) NOT
NULL, CONSTRAINT PK_MATERIA PRIMARY KEY(Idmateria))
En las siguientes imágenes mostramos los problemas que se pueden presentar si nos olvidamos
algunas reglas.
1) CREATE TABLE Materias2(Idmateria INT NOT NULL, nom_materia VARCHAR(40) NOT NULL,
CONSTRAINT PK_MATERIA PRIMARY KEY(Idmateria))
Como se puede apreciar, no hay problema al usar el mismo nombre de clave primaria
2) CREATE TABLE Alumnos2(DNI INT NOT NULL, Apellido VARCHAR(40) NOT NULL, Nombre
VARCHAR(40) NOT NULL, Fecha_nac DATE NOT NULL, email VARCHAR(35) NOT NULL, telefono
VARCHAR(12) NOT NULL, direccion VARCHAR(70) NOT NULL, Idlocalidad INT NOT NULL,
CONSTRAINT PK_ALUMNO PRIMARY KEY(DNI),
CONSTRAINT FK_LOCALIDAD FOREIGN KEY(Idlocalidad) REFERENCES Localidades(Idlocalidad))

Ocurre el error porque los nombres de claves foráneas no se pueden repetir dentro de la misma base de
datos
3) CREATE TABLE Alumnos2(DNI INT NOT NULL, Apellido VARCHAR(40) NOT NULL, Nombre
VARCHAR(40) NOT NULL, Fecha_nac DATE NOT NULL, email VARCHAR(35) NOT NULL, telefono
VARCHAR(12) NOT NULL, direccion VARCHAR(70) NOT NULL, Idlocalidad INT NOT NULL,
CONSTRAINT PK_ALUMNO PRIMARY KEY(DNI),
CONSTRAINT FK_LOCALIDAD2 FOREIGN KEY(Idlocalidad) REFERENCES Localidades(Idlocalidad))
Se puede crear la tabla Alumnos2 al cambiar el nombre de la clave foránea.
Ahora vamos a renombrar ambas tablas con el BrowserSQL y vamos a utilizar también la consola de
MySQL para obtener el listado de tablas antes y después de los cambios

Como podemos ver, los objetos son sensibles a mayúsculas y minúsculas, una característica de la mayoría
de las bases de datos y de Linux y otros sistemas operativos basados en Unix. Alumnos y alumnos son
objetos diferentes.
Sentencia DROP
Esta sentencia permite eliminar un objeto, por ejemplo, una tabla, vista, etc.
DROP TABLE nombreTabla
Como en el caso de las creaciones de tablas (o las inserciones), si tenemos que tener en cuenta la
estructura lógica de la base de datos. Así como no podemos crear la tabla Notas o insertar en la tabla
Notas registros si no tenemos creada primero la tabla Alumnos y la tabla Materias, o datos en las
mismas para insertar en Notas; tampoco podemos eliminar la tabla Materias porque se usa en Notas;
es decir, si quisiéramos eliminar todas las tablas de la base de datos pues deberíamos empezar por
eliminar las tablas más derivadas o dependientes; es decir aquellas que utilizan referencias a otras
tablas deben eliminarse primero; es decir, primero Notas, luego Alumnos, Materias o Localidades,
como son primarias, no interesa si Localidades se elimina primero o después que Materias.
Las tablas renombradas fueron elegidas a propósito y pudimos eliminarlas sin problemas ya que no están
relacionadas entre sí y si bien la tabla alumnos tiene una clave foránea es justamente más dependiente
que la tabla a la que referencia, Localidades.

3. SQL – DDL: Sentencias INSERT, UPDATE, DELETE y SELECT
Sentencia INSERT:
Esta sentencia sirve para agregar registros a una tabla.
La sintaxis es:
Sintaxis:
INSERT INTO nombreTabla (atributo1,atributo2, …, atributon)
VALUES(valor_atributo1, valor_atributo2, …, valor_atributon)
Como material complementario se distribuyen los archivos de script. Dichos archivos han seguido la
secuencia lógica de inserción; esto quiere decir, que para insertar datos en las tablas tenemos que tener
en cuenta el diseño lógico, en particular el MER: hay que empezar por las tablas primarias y recién después
por las tablas derivadas o dependientes, de las menos dependientes a las más dependientes (es decir, la
misma lógica que al crear las tablas).
En base a nuestro modelo de datos la secuencia sería así: Tabla Localidades o tabla Materias en primer y
segundo lugar, la Tabla Alumnos y finalmente la Tabla Notas;
Ingresaremos un Alumno, recordando que tenemos los datos insertados en la tabla Localidades.
El alumno a ingresar tendrá estos datos: dni: 45200104, apellido: SANCHEZ, nombre: JUAN IGNACIO,
la fecha de nacimiento: 28/12/1995, la direccion: San Luis 355, idlocalidad=1, email:
jisanchez@hotmail.com y telefono: 4235444
La sentencia por lo tanto es:
INSERT INTO Alumnos(DNI, Apellido, Nombre,Fecha_nac,email,telefono,direccion,Idlocalidad)
VALUES(45200104,'SANCHEZ','JUAN IGNACIO','1995-12-
28','jisanchez@hotmail.com','4235444','San Luis 355',1)
Hemos insertado el alumno en la base de datos que tenemos en MySQL. Si se hace una consulta
sobre la tabla tendremos un solo alumno
Sin embargo en el archivo de scripts puede verse que MySQL permite realizar varias inserciones
en una sola línea:

Sentencia UPDATE:
Esta sentencia nos permite modificar uno o más registros que ya existen en la tabla.
La sintaxis para modificar un registro en particular es:
Sintaxis:
UPDATE nombreTabla SET atributo1=nuevo_valor_atributo1,
atributo3=nuevo_valor_atributo3,
atributon = nuevo_valor_atributon WHERE atributo_que_esPK=valor
Para modificar más de un registro implica que no nos interesa la clave primaria sino que se cumpla una
condición particular con uno o más atributos. Esto lo veremos con ejemplos, ya que así es mucho más
claro.
Vamos a modificar un dni, que a su vez es clave primaria puesto que está mal ingresado. En teste caso
también hay que tener en cuenta que si el alumno está inscripto en las materias, habrá que modificar
también la tabla Notas, ya que en esta tabla dni es una clave foránea.

DELETE:
La sentencia básica para eliminar un registro tiene la siguiente sintaxis:
Sintaxis:
DELETE FROM nombreTabla WHERE atributo_que_esPK=valor
Hay que tener mucho cuidado!! Porque si nos olvidamos de establecer qué registro queremos borrar, y
hacemos algo así:
DELETE FROM nombreTabla ¡¡¡OJO!!
Porque eliminaríamos todos los registros de la tabla.
Hay una situación particular donde no se pueden borrar los registros de la tabla. Sería el
caso de la tabla Notas, que es dependiente de la Tabla Alumnos. Esto se debe al diseño
lógico y físico de la base de datos, y a las normas de integridad referencial que hemos
utilizado por omisión. Es así que, mientras existan alumnos, no se podrán borrar sus notas.
Sentencia SELECT sobre una tabla:
Sentencia básica
Sintaxis: SELECT * FROM tabla
El resultado de esta sentencia es el total de los registros de la tabla
Ejemplo: mostrar todos los registros o tuplas de la tabla Localidades
Importante: los nombres de las tablas son objetos, debemos usarlos considerando mayúsculas y
minúsculas. Si no nos acordamos vamos a la solapa Metadatos y consultamos los Objetos de la Base de
Datos.

Sentencia SELECT con proyección
Sintaxis: SELECT col1,col4,col6 FROM tabla
El resultado de aplicar esta sentencia es que obtenemos todas las filas pero se muestran sólo las
columnas indicadas.
Ejemplo: mostrar el DNI, apellido y nombre de los alumnos
Sentencia SELECT con restricción
Sintaxis: SELECT * FROM tabla WHERE condición
El resultado de aplicar la sentencia es que se devuelven sólo las filas o tuplas que coinciden con la
condición.
Ejemplo: mostrar los alumnos cuya idlocalidad es igual o mayor a 2

Sentencia SELECT mixta
Sintaxis: SELECT col1,col4,col6 FROM tabla WHERE condición
El resultado de esta sentencia es que se devuelven las tuplas que coinciden con la expresión de la
condición y sólo se muestran los datos de las columnas o atributos indicados.
Ejemplo: mostrar el dni, apellido, nombre de los alumnos cuyo idlocalidad es igual a 1

Sentencia SELECT sobre más de una tabla
En este caso utilizaremos la Unión de tipo join, es decir aplicaremos las nociones teóricas vistas sobre
claves primarias y foráneas.
Sintaxis: SELECT tabla1.col2, tabla2.col1, tabla3.col2 FROM tabla1,
tabla2, tabla3 WHERE tabla1.id_clave = tabla2.id_clave
AND tabla2.id_clave = tabla3.id_clave
Ejemplo: mostrar el dni, apellido, nombre, dirección y nombre de la localidad de los alumnos
En este ejemplo la unión es de dos tablas. Así mismo hemos utilizado alias de tablas, lo cual hace
mucho más fácil la escritura y también la consulta más rápida.
Ejemplo: mostrar los alumnos inscriptos en las materias, indicando el nombre de la materia, el dni,
el apellido y el nombre de los alumnos
Lo importante aquí es comprender que la tabla Notas es la más derivada y que por cierto vincula a
Materias y a Alumnos, por ende necesitamos unir tres tablas, como se puede apreciar en la siguiente
imagen.

Ahora, por ahí sería mejor ordenar los resultados por nombre de materia, cosa que se puede llevar a
cabo con la siguiente senTencia
Cláusula ORDER BY
La sintaxis de esta cláusula es … ORDER BY col1,col2 [ ASC | DESC] siendo predeterminada la
ordenación ascendente.
Ejemplo: el mismo ejemplo anterior ordenando en forma ascendente la consulta en función del
nombre de la materia

Si también quisiéramos ordenar por apellido:
Como vemos ordena en forma ascendente por apellido. Si queremos ordenar en forma descendente
deberíamos escribir DESC después de apellido.
Importante: como puede apreciarse los nombres de columnas pueden escribirse sin respetar
mayúsculas/minúsculas porque no se trata de un objeto sino de un atributo del objeto, en este caso una
tabla.
Ahora ordenaremos también por Nombre, tanto el Apellido como el Nombre en forma descendente
Como también puede apreciarse en la imagen, las palabras reservadas del lenguaje SQL que utiliza
MySQL pueden escribirse en mayúsculas o minúsculas (caso del último desc)

Cláusula LIKE
Esta cláusula permite realizar una restricción donde la condición implica la comparación entre
cadenas. Básicamente la sintaxis utiliza el carácter comodín %.
Hay tres casos básicos. Tomaremos como ejemplo la tabla alumnos y el atributo nombre o el atributo
apellido.
Caso 1: conocer los alumnos cuyo nombre empieza con la letra M
SELECT * FROM Alumnos WHERE nombre LIKE 'M%'
Las comillas indican que es una cadena y el símbolo % después de la letra M indica al DBMS que no
interesa el resto de la cadena.
Caso 2: conocer los alumnos cuyo apellido termina en EZ, la consulta será:
SELECT * FROM Alumnos WHERE apellido LIKE '%EZ'

Caso 3: si se quiere saber qué alumnos tienen en el apellido la C
SELECT * FROM Alumnos WHERE apellido LIKE '%C%'
Si hubiéramos solicitado al DMBS conocer qué alumnos tienen en el apellido los caracteres CH,
entonces tendríamos que haber escrito SELECT * FROM Alumnos WHERE apellido LIKE '%CH%'
En este caso, la consulta no devolvería ningún resultado porque ningún alumno tiene estos caracteres
entre el conjunto de caracteres de sus apellidos.
Lógicamente es posible combinar varias sentencias, como pueden consultar en el material propuesto.

4. Caso práctico: ajustando el diseño físico de la BD Escuela. Aplicación
práctica de tipos de Datos, ALTER TABLE, RENAME, DROP, etc.
Este es el Diseño Físico inicial de la Base de Datos Escuela, que además ya está implementado y
funcionando.
Si fuera necesario implementar ajustes en el diseño físico, más que nada relativos a ajustar tipos de
datos tendremos que aplicar cambios importantes, para lo cual contar con en backup de la base de
datos en forma permanente y periódica es fundamental.
Diseño Físico Inicial de la BD Escuela
De un análisis más acabado surge que difícilmente se tengan tantas materias como para usar el tipo
de datos INT o INTEGER. Más apropiado sería elegir SMALLINT o inclusive TINYINT que son todos
tipos de datos enteros pero con diferente precisión.
Si damos un vistazo a la Ayuda de la Versión 5.7.29 de MySQL, la que actualmente estamos
utilizando, desde la consola podremos ver que:
Tipo de Datos Valores con signo Valores sin signo
INT -2147483648 a 2147483647 0 a 4294967295
SMALLINT -32768 a 32767 0 a 65535
BIGINT
-9223372036854775808 a
9223372036854775807
0 a 18446744073709551615
Todos estos tipos de datos (el listado no es completo, consultar en la ayuda) admiten valores positivos
y negativos (lo mismo sucede con los números reales). Entonces, a amenos que se especifique lo
contrario, tomarán valores dentro de un rango específico comprendiendo negativos como positivos.
En general podría decirse que el único peligro al cambiar el tipo de datos de una columna podría ser
que se perdieran parte de los datos, al truncarse el contenido de la columna modificada; por lo tanto
la primera regla es tener en cuenta este factor, muy importante: que no se vayan a truncar
datos. Sin embargo otro problema bastante más complejo es si el atributo a modificar es además
clave primaria o clave foránea ya que podrían generarse problemas.
Si además las tablas tienen datos; es decir se trata de un sistema en producción, el problema puede
ser bastante más problemático y riesgoso; un motivo más por el cual es fundamental realizar los
backups en forma permanente y continua.
Si bien podemos dejar la clave primaria de la tabla Localidades como está, con el código postal
haremos el supuesto de que sólo necesitamos almacenar códigos de Mendoza. En el diseño físico
actual sólo se aclara que es una clave candidata (a ser primaria) o lo que es lo mismo que es una
clave única, que no se repite. Sin embargo nada se especifica respecto al rango de valores que
deberán tomar, y esto sí es importante tenerlo en cuenta también.

Si revisamos la sentencia CREATE TABLE veremos que esta versión de MySQL cuenta con los
siguientes CONSTRAINTS:
 Clave Primaria
 Clave Foránea
 Clave Única
Esta última regla de integridad referencial es la que se aplica a aquellos campos que, por su lógica son
únicos, y si bien no lo vemos en la materia, es importante saberlo.
Pero de esta lista falta un constraint, en esta versión, que es importante porque se relaciona en forma
directa con el rango de valores que puede tomar un tipo de datos: el CONSTRAINT CHECK y que en
esta versión y anteriores no está implementado.
Esta es una regla de integridad referencial muy importante y aunque no nos garantiza su buen uso en
DBMS pagos como SQL Server u Oracle, por ejemplo, sí nos facilita bastante el trabajo de diseño ya
que nos permite implementar validaciones de los datos al nivel más bajo del sistema: al nivel de la
base de datos misma.
Ejemplo: queremos que los códigos postales sean sólo los de Mendoza, entonces habrá que verificar
que estén comprendidos entre 5500 y 5699 ya que San Luis tiene el código postal 5700. Se podría
implementar de esta manera en la medida que el DBMS cuente con el CONSTRAINT CHECK.
Todavía sería más importante, si tentemos en cuenta que el tipo de datos SMALLINT sin SIGNO
permite almacenar valores desde el 0 la 65535, con lo cual un rango muy grande de valores no
deberían ingresarse para el código postal sólo de Mendoza.
Si tuviéramos el CHECK CONSTRAINT en MySQL pues diríamos que los valores válidos deben estar
comprendidos entre el 5500 y el 5699, con lo cual cualquier intento de insertar un valor que no esté
en el rango no sería permitido.
En conclusión, además de elegir un tipo de datos lo más cercano al dominio, también a lo que vamos
a almacenar (el TINYINT no nos sirve, porque sin considerar los negativos sólo podríamos almacenar
valores por debajo además del código 5500); por otro lado el INT es muy grande, entonces el más
cercano es el SMALLINT).
Como la versión de MySQL no contempla el CHECK, entonces, ya se trate que definamos el campo con
el tipo de datos SMALLINT con o sin signo, o sea:
CREATE TABLE Localidades(…, cod_post SMALLINT NOT NULL,…) o bien
CREATE TABLE Localidades(…, cod_post SMALLINT UNSIGNED NOT NULL, …)
Deberemos implementar la validación en el nivel superior de la arquitectura, en la del formulario.
Muchas veces para solucionar estos problemas directamente creamos las tablas con los valores
específicos y no permitimos su modificación, de modo tal que el usuario utilice una lista, por ejemplo.
Sin embargo en la materia, por cuestiones didácticas, nos manejaremos con cuadros de texto de Java
Swing, o sea, JtextFields.
Otro ejemplo es el DNI o el CUIT, que sabemos que en el mundo real no pueden ser números
negativos. Hay gente además que prefiere definir el CUIT como alfanumérico porque considera los
caracteres de separación “-” que se presentan dos veces, pero se trata más que nada de la “versión
para imprimir” del código o clave, que en definitiva es un número que es calculado en forma
algorítmica, y por eso no se repite.
Además habremos notado que MySQL considera el cero como positivo, y eso sumado al hecho de que
no cuenta con el CONSTRAINT CHECK da lo mismo, en cuanto al esfuerzo de programación, el realizar
la siguiente validación en cuanto a los negativos y al cero (que si además, por lo que se expone en un
video sobre los valore slógicos, si no queremos confundirlo al cero con el falso, habría que excluirlo):
Si (txtCodigoPostal = 0) entonces
Mostrar “El campo código postal no admite el valor cero”
FinSi
o sino
Si (txtCodigoPostal <= 0) entonces
Mostrar “El campo código postal sólo admite valores mayores que cero”
FinSi

Pero puede no ser lo mismo en cuestiones prácticas y puntuales: debemos elegir el tipo de datos más
apropiado y ajustado a la realidad de lo que representará (aunque nunca vamos a poder tener algo
perfecto sí una aproximación lo más ajustada), con lo cual, no hay que olvidar que el cero es
considerado como positivo pero también como alias del falso para cualquier entero.
En resumen, el fin de la materia no sólo es que sepan programar sino crear su propio criterio para lo
cual es preciso entender que todo lo que existe tiene su pros y sus contra, y lógicamente el software y
los DBMS no son la excepción.
Así pues debemos conocer el que vamos a implementar, y no olvidarnos que habrá casos en que nos
encontraremos con empresas que usan DBMS propietarios de diferentes autores, unos serán
opensource, otros no, todos con diferentes versiones y ciertamente unos serán multiplataforma y
otros no e inclusive toda esta variedad corriendo sobre diferentes software de base o bien pudiendo
acceder desde distintos sistemas operativos. Por ende, baste decir, que no hay nada que represente
una verdad absoluta en lo informático, salvo la verdad fáctica, que lo más importante es la
información, que debe ser precisa y poderse obtener en tiempo y forma.
No tenemos que olvidar que el fin principal por el cual guardamos datos y generamos información es
para tomar buenas decisiones y para eso es necesario contar con información precisa pero
además, y fundamentalmente, cuando se la necesita, ya que si fuera muy precisa pero tarde
tampoco serviría… o sería un esfuerzo en vano.
Caso práctico:
Caso práctico:
Así pues se ha mejorado el Diseño Físico inicial considerando las propias necesidades de nuestro caso
didáctico y ciertamente los tipos de datos con que cuenta el DBMS que se ha elegido.
Diseño Físico Ajustado de la BD Escuela
Como se puede apreciar deberemos llevar a cabo varias modificaciones, con datos ya insertados
además; es decir con un sistema funcionando o como se suele llamar en la práctica, en producción.
Entonces, y sólo utilizando la consola de MySQL pues empezaremos por los cambios más simples, que
son los que involucran a una sola tabla o bien no involucran relaciones entre tablas.

Ajuste del Diseño Físico utilizando la sentencia ALTER TABLE
Ajuste del Diseño Físico utilizando la sentencia ALTER TABLE
Crearemos nuevamente la base de datos con sus inserts para lo cual utilizaremos los archivos de
script del backup original. Es importante saber que el archivo de script, si está bien armado, se puede
correr en MySQL vía consola pues MySQL tiene métodos automáticos para llevar a cabo backups y
recuperación de datos.
Hasta ahora nos limitábamos a escribir una sentencia por vez puesto que la materia tiene por fin que
aprendan y practiquen las sentencias SQL. Sin embargo no es menos cierto que no se puede apreciar
la utilidad del backup en sí sin un ejemplo, como puede verse en el video Recrear Base de Datos
desde el backup completo. En menos de 5 minutos recuperan los datos. Lleva más tiempo buscar
los archivos de backup que correr el backp en la consola de MySQL.
En el segundo video ya sí nos abocamos a aplicar las sentencias del script con las sentencias ALTER
TABLE que nos sirven para modificar el diseño físico. Sí hay que tener en cuenta que no es igual si el
sistema ya está en producción (es decir, tiene datos insertados).
La reglas básicas a seguir son:
1) verificar visualmente (o con algoritmos en el caso de sistemas grandes) que no se vaya a producir
un truncamiento de datos
2) segundo utilizar ALTER TABLE con columnas que no son claves
3) si debemos modificar el diseño físico de un atributo que es clave primaria y no tiene foráneas se
modifica el mismo con ALTER TABLE
4) si debemos modificar el diseño físico de una columna que es clave primaria y tiene foráneas en
otras tablas:
 primero se elimina la clave foránea (ALTER TABLE nombreTabla DROP FOREIGN KEY
nombreClaveForanea)
 luego se modifican ambas tablas con los tipos de datos correctos
 se vuelve a crear la clave foránea con el CONSTRAINT FOREIGN KEY
5) Si hay que modificar el nombre de una clave se elimina con
 ALTER TABLE nombreTabla DROP FOREIGN KEY nombreClaveForanea o bien
 ALTER TABLE nombreTablas DROP PRIMARY KEY
 Luego se vuelve a crear la clave en cuestión con el nombre correcto

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

Más contenido relacionado

La actualidad más candente

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

Último

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