Constraints o Restricciones

Clase 14 de 63 • Fundamentos de Bases de Datos 2017

Clase anteriorSiguiente clase

Resumen

Datos importantes:

Las restricciones se pueden trabajar desde la Base de Datos. Normalmente las validaciones con restricciones se hacen desde la aplicación, pero es importante tener en cuenta que podemos hacerlo de igual forma desde la Base de Datos.
Las llaves primarias y las llaves foraneas no solamente tienen la restricción Not null, sino que además tienen la restricción unique, no puede haber otra igual.
Con check, las validaciones que podemos hacer son: Igual, mayor o igual, menor o igual, mayor qué o menor qué.

Ivan Robles

student•

Ejemplos de restricciones:

Validación si una persona tiene cierta edad (> 18 años)
El campo no puede estar vacío Not Null
El campo no se puede repetir Unique
Validación por comparación Check (==, >=, <=, ><)

Un tipo de validación desde la base de datos que se me ocurre es; en un ecommerce, restringir el acceso a ofertas o descuentos especiales, a un tipo de usuario (Normal o Premium).

Luis Scozzese

student•

(==, >=, <=, >,<) creo que así mejor 😄

Ivan Robles

student•

Es que el ultimo =>.<= es como un gatito!! 😃

christian jordy mamani sucasaire

student•

Diferencia entre Primary key vs Unique
Cosas en comun

Una clave primaria implica un índice único.
Cosas que son diferentes
Sólo puede haber una clave primaria, pero puede haber múltiples índices únicos.
Una clave primaria implica también NOT NULL, pero un índice único puede ser nulo.

Paola Medina

student•

Buen aporte

Edwin Alfredo mejia pinto

student•

Aquí están los ALL_CONSTRAINS de oracle
https://docs.oracle.com/cd/B14117_01/server.101/b10755/statviews_1037.htm#i1576022

NOT NULL  =   campo obligatorio.
CREATE TABLE Customer
(SID integer NOT NULL,
Last_Name varchar (30) NOT NULL,
First_Name varchar(30));

UNIQUE = Asegura que todos  los valores en una columna sean distinto
CREATE TABLE Customer
(SID integer Unique,
Last_Name varchar (30),
First_Name varchar(30));

CHECK = Todos los valores en una columna cumplan ciertas condiciones 
CREATE TABLE Customer
(SID integer CHECK (SID > 0),
Last_Name varchar (30),
First_Name varchar(30));

Jose Luis Marin Escamilla

student•

Este si es un buen aporte

Andrés Medina Arroyave

student•

Así mas claro... Gracias

Erick Neftalí Sarmiento Cortes

student•

Las restricciones desde la base de datos nos pueden recordar que no podemos ingresar un dato u omitirlo sin importar que no lo hayamos restringido en la capa de aplicación, es como una segunda capa de seguridad.

Daniel Gomez

student•

La cláusula NOT NULL indica que la columna no podrá contener un valor nulo, sera obligatorio el ingreso de valores.

La cláusula **CONSTRAINT ** sirve para definir una restricción que se podrá eliminar cuando queramos sin tener que borrar la columna. A cada restricción se le asigna un nombre que se utiliza para identificarla y para poder eliminarla cuando se quiera.

La cláusula PRIMARY KEY se utiliza para definir la columna como clave principal de la tabla. Esto supone que la columna no puede contener valores nulos ni pueden haber valores duplicados en esa columna, es decir que dos filas no pueden tener el mismo valor en esa columna.

La cláusula **UNIQUE ** sirve para definir un índice único sobre la columna. Un índice único es un índice que no permite valores duplicados, es decir que si una columna tiene definida un restricción de UNIQUE no podrán haber dos filas con el mismo valor en esa columna. Se suele emplear para que el sistema compruebe el mismo que no se añaden valores que ya existen.

La cláusula NOT NULL indica que la columna no puede contener valores nulos, cuando queremos indicar que una columna no puede contener el valor nulo lo podemos hacer sin poner la cláusula CONSTRAINT, o utilizando una cláusula CONSTRAINT.

Alexander Enrique Guzman Ruiz

student•

Gracias

Smerlyn Javier Eusebio Bonifacio

student•

Maurcio Herrera M

student•

Saludos a todos,
Tengo una duda: ¿Cuál de las dos opciones de validaciones es más eficiente en consumo de recursos y en velocidad de respuesta, las realizadas por la aplicación o por las de la base de datos? y ¿es recomendable usar las dos o con implementar una de éstas es suficiente? 🤔

Diego Forero

Team Platzi•

Las validaciones deben hacerse en el frontend para asegurarse que los datos se envíen completos y con el tipo de dato correcto, esto ayuda a que el usuario no tenga que esperar una respuesta del servidor para saber que los datos están mal, también se deben realizar en backend para asegurarse de que los datos sean los correctos ya que la validación por frontend se puede saltar si modifican el dom desde las herramientas de desarrollador o deshabilitan JavaScript, esto ayuda a evitar errores en la aplicación y poder enviar el error rápidamente al usuario, la última validación que es la que hace la base de datos se hace de forma automática por parte de esta ya que si tienes un campo de tipo entero y recibe un string va a retornar un error, pero el ideal es que no lleguen errores de este tipo ya que toma más tiempo darle la respuesta al usuario para decirle que hay un error.

Maurcio Herrera M

student•

Muchas gracias por tu explicación. 👏

Pablo Martinez

student•

Para asegurar la integridad de los datos almacenados en nuestras tablas, podemos crear restricciones, algunos los hemos utilizado sin querer o simplemente desconocemos que lo que hicimos fue una restricción, por ejemplo una llave primaria. Estas restricciones las podemos implementar al momento de crear nuestras tablas o de modificarlas, también es necesario señalar que dichas restricciones son objetos propios de la base de datos y por lo tanto requieren de un nombre único compuesto del nombre del esquema al que pertenece y el nombre que lo identifica, un ejemplo sería nombreEsquema.nombreRestriccion.

Los diferentes tipos de restricción que existen son:
PRIMARY KEY
UNIQUE
FOREIGN KEY
CHECK
DEFAULT

Alejandro Madrid Felizzola

student•

Not null entra en esta lista?

Daniel Luque Soria

student•

Sí

Julian Andres Builes Cajiao

student•

la Llave primaria y la foráneas son Not Null y a su vez es Unica.

Juan Carlos Pinzón

student•

La llave foránea podría ser nula, aunque no es lo recomendado.

Cesar David Ramírez Dimaté

student•

Pensé que no, pero si puede ser nula jajaja.

CREATE TABLE `basics_bd`.`Persona` (
  `idPersona` INT NOT NULL,
  `nombre` VARCHAR(45) NULL,
  PRIMARY KEY (`idPersona`));

CREATE TABLE `basics_bd`.`Telefono` (
  `idTelefono` INT NOT NULL,
  `numero` INT(10) NULL,
  `idPersona` INT NULL,
  PRIMARY KEY (`idTelefono`),
  INDEX `fk_telefono_persona_idx` (`idPersona`),
  CONSTRAINT `fk_course__teacher`
    FOREIGN KEY (`idPersona`)
    REFERENCES `basics_bd`.`Persona` (`idPersona`));

INSERT INTO `basics_bd`.`Persona` (`idPersona`, `nombre`) VALUES ('1', 'David');
INSERT INTO `basics_bd`.`Telefono` (`idTelefono`, `numero`) VALUES ('1', '273123');

Daniel Quispe

student•

Es necesario hacer validaciones desde base de datos y desde la capa de aplicación

Hinder Adrian Alvarez Perlaza

student•

Así es, pues puede ocurrir que en el momento de la fase de programación se nos olvide validar la restricción, entonces la base de datos nos avisará sobre el incumplimiento de la condición y evitará que se ingrese una tupla con información no permitida.

David Auza

student•

Un ejemplo de restricción puede ser cuando algunas tiendas virtuales en Estados Unidos no permiten que el comprador ingrese una tarjeta de crédito extranjera.

Javier Insuasti Morales

student•

Que tan recomendable es tener restricciones como CHECK desde la BD? El performance no se ve afectado? (pensandose en grandes cantidades de datos)

Diego Forero

Team Platzi•

Se pueden tener como validación adicional, pero siempre debes validar todo en el backend para que no lleguen transacciones a la base de datos que puedan dar error ya que igual ocupa la base de datos y si son muchas peticiones simultaneas puedes tener una baja en el rendimiento.

Camilo Caquimbo Tabares

student•

Creo que la tendencia para grandes cantidades de datos es hacer la mayoría de validaciones en frontend, para eso los navegadores han evolucionado muchísimo y así reducir la carga de procesamiento en la base de datos.

Ivan Yovera

student•

Las restricciones quizá podrían servir para evitar la presencia de caracteres especiales en campos donde solo se esperan letras y números. ¿Cómo se haría en éste caso?

Cesar David Ramírez Dimaté

student•

De lo que he visto esto no se realiza desde bases de datos sino se debe hacer desde la capa de aplicación a través de expresiones regulares.

Analia De La Reta

student•

El de numerico al solo hecho de declarar el campo tipo number no te va a permitir ingresar un caracter y dara un error de insercion. los caracteres como dice Cesar

Gustavo Quispe Ramos

student•

restricciones: Unique : Utilizado para la llave primaria o forania de una tabla que garantiza que no se repita el id. not null: : El campo no puede estar vació. check: Validacion de comparación, se aplica a un campo a evaluar

Karla Verónica Álvarez Vázquez

student•

Julia Maria Reyes Salvador

student•

¡Que chiva su camisa, profe!

Jairo Lachira Peralta

student•

¿De que manera muestro el error de la restricción desde la base de datos en el front-end?

Irving Juárez

student•

Buena pregunta, aunque seria mas como, como muestro las restricciones desde la base de datos, no? Ya que desde ahí se hizo el constraint

Julio César Maldonado Delgado

student•

Que es una capa de aplicaciòn?

Ingeborg Muñoz Carnot

student•

Hola, se refiere a que uno maneja esas restricciones desde la aplicación, a nivel de código en por ejemplo tu aplicación java o php y no directamente en la base de datos como él está explicando.

No sé sí te quedó un poco más claro.

Saludos.

Victor Daniel Aguirre Gil

student•

Es la capa donde se ejecuta tu código fuente.

Diego Herrera

student•

Restricción

Entidad Persona * Edad(obligatorio) * Fecha nacimiento(obligatorio)

obligatorio es Not null
Unique (único)
< menor que

mayor que
== igual a

Antonio Cuellar Perdomo

student•

Interesante saber sobre restricciones!

Constraints o Restricciones

Introducción al Curso Fundamentos de Bases de Datos

¡Vamos a renovar este curso!

Introducción al Curso de Bases de Datos

Teoría general de Bases de Datos

Propósito general de las Bases de Datos

Tipos de Bases de Datos y sus aplicaciones en la industria

Visión general de los datos

Tipos de Datos

Diferentes tipos de Bases de Datos

Reto ¿Hadoop y Blockchain podrían cambiar una Base de Datos tradicional?

Bases de Datos Relacionales

¿Qué es una Entidad?

¿Qué es una Relación?

Características o datos de una Entidad

¿Ya aparecieron las llaves?

Índices e Indexación

Constraints o Restricciones

Capas de abstracción del modelo Entidad-Relación

Metodología básica de 9 pasos con Barker (Paso 1) Identificar Cuáles son las Entidades Resuelven Nuestro Problema

Metodología básica de 9 pasos con Barker (Paso 2): Identificación de las Relaciones de las Entidades.

Metodología básica de 9 pasos con Barker (Paso 3): Entidades y Relaciones

Metodología de Diseño (Correcciónes del paso 2 y 3)

Metodología de Diseño (Paso 4): Asignar Atributos a las Entidades.

Metodología de Diseño (Solución del paso 4): Terminando de Asignar Atributos a las Entidades

Metodología de Diseño (Pasos 5, 6 y 7) 5. Generar un diagrama conceptual, 6. Modelo lógico, 7. Identificar nuevos atributos que generan nuestras entidades débiles.

Metodología de Diseño (Paso 8): Construir el Diagrama del Modelo Físico

Metodología de Diseño (Paso 9): Pasar al estándar de la base de datos (SQL)

Reto con el paso 4 de la Metodología de Diseño

Bases de Datos NO Relacionales y Otros tipos de Bases de Datos

Atomicidad y consistencia

Aislamiento y durabilidad

Bases de Datos In-Memory (Cambio de árboles a columnar)

Otros tipos de Bases de Datos en la industria

Bases de Datos In-Memory con indexación de columnar

Definiendo el Proyecto y Generando Entidades de PlatziStore: Pasos 1 y 2

Definir la Estructura de la Tabla Cliente del Proyecto: Pasos 3 y 4

Terminando de Estructurar Nuestras Tablas (Continuación del paso 4)

Metodología de Diseño (Paso 5): Diagrama Conceptual

Metodología de Diseño (Paso 6 y 7): Modelo Lógico y Entidades Débiles

Solución de atributos de entidad del proyecto - Atributos adicionales a entidad débil creada

Metodología de Diseño (Paso 8)

Llevando nuestro proyecto a SQL (Paso 9)

Terminando la Implementación del Proyecto (Paso 9)

Dependencias funcionales

Normalización, llevando el proyecto hasta tercera forma normal (primera forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (segunda forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (Cuarta y quinta forma normal)

Comenzando con SQL

DDL: Data Definition Language y DML: Data Manipulation Language

ACID desde lo no relacional

CAP

Scale Out y Scale Up

¿Scale out o Scale up?

DBMS en nube para poder iniciar una aplicación propia

IMPORTANTE: Preparación del entorno de trabajo

Estructura básica de un Query

Aprendiendo a Hacer más Querys

Estructura básica del Query con más de una tabla

Estructura básica del Query con más de una tabla 2

Tuplas y más tuplas

Insertar registros

Joins

Noo SQL Aplicado, Planteando el Problema

Aplicando NoSQL: Colecciones y Shards

Aplicando noSQL: Integración de Comunicaciones y Hardware en una Base de Datos Scale OUT

Aplicando noSQL: Integrando JSON a Bases de Datos No Relacionales

Conclusiones del curso

Datos importantes: