Está en la página 1de 26

CPEL - CARRERAS UNIVERSITARIAS

PARA PERSONAS CON EXPERIENCIA LABORAL

Base de datos

Prof. Carlos Takano


Semana 2

CPEL - CARRERAS UNIVERSITARIAS


PARA PERSONAS CON EXPERIENCIA LABORAL

Diseo de base de datos


relacional

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Fases en el diseo de base de datos

Elmasri, R., & Navathe, S. (2011). Fundamentals of database systems (6th ed., p. 201).
Boston: Addison-Wesley.

CPEL - CARRERAS UNIVERSITARIAS


PARA PERSONAS CON EXPERIENCIA LABORAL

Modelo conceptual de datos

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Modelos

Un modelo es
Una

abstraccin, una descripcin simplificada y


aproximada de la realidad
Para un propsito especfico, se enfoca en un
aspecto particular de inters
Una herramienta para comprender, aprender y
evaluar opciones
Un vehculo de comunicacin entre los diferentes
grupos de inters

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Modelo conceptual de datos


Debe describir con precisin y claridad las
necesidades de informacin del negocio
Facilita la comprensin del negocio y la
evaluacin de opciones
Proporciona una base slida para el
diseo lgico y fsico de base de datos

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Ejemplo diagrama Entidad-Relacin

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Ejemplo diagrama Entidad-Relacin


Departamento

Puesto

Cdigo departamento

Cdigo puesto

Nombre departamento
Ubicacin departamento

Descripcin puesto

Empleado
Cdigo empleado
Competencia
Cdigo competencia
Descripcin competencia

Nombre empleado
email empleado
Cdigo departamento
Cdigo puesto

Tipo relacin
Tipo relacin

Dependiente
Cdigo empleado
Nombre
Tipo relacin

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Notacin: Entidad
Asociado
DNI
Nombres
Apellido paterno
Apellido materno
Direccin
email
Telfono
Gnero
Fecha nacimiento

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Notacin: Relaciones

CPEL - CARRERAS UNIVERSITARIAS


PARA PERSONAS CON EXPERIENCIA LABORAL

Normalizacin

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Dependencia funcional
Reglas o restricciones que se debe
cumplir
Son el objetivo
Para un determinante, la funcin devuelve
un dependiente
Claves determinan funcionalmente los
atributos no clave

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Anomalas
Son los sntomas de un problema
Insercin
Actualizacin
Eliminacin

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Redundancia

Es la causa

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Normalizacin

Es la solucin
Descomponer una relacin en otras
Mantener la informacin acerca de una cosa
en un solo lugar
Inconsistencia=violacin / infraccin de
integridad
Ejemplos
Direccin:

texto vs. estructura


Supertipos y subtipos

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Ejemplos
Claves
Casos

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Diseo de esquemas relacionales


Puede haber muchos diseos
Algunos mejores que otros
Cmo elegir?

diferentes

Ejemplo:
Todos los atributos en una sola relacin
Redundancia, cantidad de tuplas
Actualizacin -> inconsistencia

Eliminacin -> prdida de informacin


Mostrar diseo normalizado

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Boyce-Codd normal form is stricter than fourth normal form.


Specifically if we make a big Venn diagram here of all the relational designs that satisfied
Boyce-Codd Normal Form, which by the way is very often abbreviated BCNF, then that
contains all of the relations that satisfy fourth normal form, normally abbreviated 4NF.
So every relation that's in fourth normal form is also in Boyce-Codd normal form, but not
vice versa.
You might be wondering what happened to first, second and third, normal forms.
So first normal form is pretty much just a specification that relations are real relations with
atomic values in each cell.
Second normal form is specifying something about the way relations are structured with
respect to their keys.
Neither of those is discussed very much anymore.
Third normal form is a slight weakening of Boyce-Codd normal form and sometimes people
do like to talk about third normal form.
So you can think of third normal form as a little bit of a even bigger circle here.
We're not going to cover third normal form in this video because Boyce-Codd normal form
is the most common normal form used if we have functional dependencies only, and fourth
normal form if we have functional and multivalued dependencies.

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Dependencias funcionales

Let's say that our student, 123Ann, applies to 7 colleges.


Then there will be 7 tuples and there will be 7 instances where we know that a student with
the social security number 123 is named Ann.
Specifically, we're going to store for every student the name and social security number
pair once for each college that they apply to.
So now let me explain what a functional dependency is and then we'll see how functional
dependencies are used to recognize when we have a bad design like this one, and to see
how we can fix it.
A functional dependency, in this case from social security number to name, and we're
saying social security number functionally determines the student name says that the same
social security number always has the same name.
In other words, every time we see 123, we're going to see Ann.
Now it doesn't necessarily go in the other direction.
It might not be that whenever we see Ann, it's 123, but whenever we see 123, it is Ann.
And so what we'd like to do is store that relationship just one time.
One time say that for 123, the name is Ann.

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

4NF

Now, let's similarly motivate the concept of multi-value


dependencies, and fourth normal form.
It is actually a little bit more complicated, but it follows the same
rough outline.
Now let's look at a different portion of the information about applying
and let's suppose, for now, that we're just concerned about students,
what colleges they're applying to, and what high schools they went
to.
We still have redundancy and update and deletion anomalies.
For example, a student who applies to Stanford is going to have that
fact captured once for every high school that they went to.
A student who went to Palo Alto high School will have that fact
captured once for every college they apply to.

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

4NF

In addition, we get a kind of multiplicative effect here.


Because let's say a student applies to C colleges and they went to H
high schools; I know students don't go to a lot of high schools but
let's suppose that this is one that had moved a lot.
In that case, we're going to have C times H, tuples.
What we'd really like to have is something more on the order of C
plus H, because then we'd be capturing each piece of information
just once.
Now the interesting thing is that the badness of this particular design
is not addressed by Boyce-Codd Normal Form, in fact this relation is
in Boyce-Codd Normal Form, because it has no functional
dependencies.
It's not the case that every instance of a social security number is
associated with a single college name or a single high school.

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

4NF

As we will see later, if there are no functional dependencies, then the relation is
automatically in Boyce-Codd Normal Form, but it's not in and fourth normal form.
So fourth normal form is associated with what are called multi-value dependencies.
When we specify a multi-value dependency as we've done here with the double arrow,
what this is saying is that if we take a particular social security number in the relation, we
will have every combination of college names that are associated with that social security
number with every high school that's associated with that social security number.
We'll actually see that when we have this multi-value dependency, we automatically have
this one, too.
I know it seems a bit complicated, and we will formalize it completely, but for now now just
think about the English statement that multi-valued dependency is saying that we are going
to have every combination of those two attributes and values in those attributes for a given
social security number.
In other words, those values are really independent of each other.
So if we have that situation, then what we should really do is store each college name and
each high school for each social security number one time, and that's what fourth normal
form will do for us.

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

4NF

Fourth normal form, similarly to Boyce-Codd normal form, says if we have a dependency,
then the left hand side must be a key.
In this case, it's a multi-value dependency we're looking at, so it's really saying something
different but the basic idea is the same which is that we want only one tuple that has each
value that's appears on the left hand side of a multi-value dependency.
So let's see what would happen, in this example, if we use our multi-value dependencies to
decompose the relation, based on the idea of fourth Normal Form.
Well it is the intuitive thing that happens.
We separate the information about the college names that a student applies to from the
information about the high schools themselves, and then we'll see that that we only store
each fact once and we do get the behavior of having C plus H tuples instead of having C
times H tuples.
Like with functional dependencies and Boyce-Codd Normal Form we'll be completely
formalizing all of this reasoning and the definitions in later videos.
A -> B, no significa que B -> A
Dependencias triviales y no triviales

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Data Definition Languaje (DDL)


Comando
CREATE

Sirve para
Crear tablas y otros objetos

ALTER
DROP

Modificar tablas y otros objetos


Eliminar tablas y otros objetos

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Diseo en desarrollo de software

Diseo, en general, es el plan para construir una


solucin
Hay ms de una manera de hacerlo
Es

un trabajo tcnico y creativo, no mecnico


Implica exploracin, descubrimiento, invencin,
desarrollo evolutivo

Estrategias:
Proceso

previo a la construccin
Disear mientras se construye

CPEL CARRERAS UNIVERSITARIAS PARA PERSONAS CON EXPERIENCIA LABORAL

Diseo en desarrollo de
software

El diseo de base de datos es parte del diseo de una aplicacin de


software
Diseo de base de datos es esttico, muestra la estructura mas no
el comportamiento
Comprende:

Modelo conceptual: investigar el dominio del problema para identificar


los conceptos principales del negocio
Diseo lgico: definir qu tablas se necesita, qu atributos tendr cada
una y sus respectivas claves primarias y otras reglas de integridad.
Definir vistas. Independiente del sistema de gestin de base de datos
sobre el que se implementar. Tcnica: normalizacin
Diseo fsico: parmetros de almacenamiento, creacin de ndices y
otros objetos para optimizar el rendimiento

También podría gustarte