http://youtu.be/sL69GUPJl8I
http://youtu.be/TYdlgnUFrtE
http://youtu.be/pnDSsxS-gcA
http://youtu.be/eoen2CYMkH4
http://youtu.be/TYdlgnUFrtE
http://youtu.be/VgG2g5ceSgs
martes, 11 de octubre de 2011
SEMANA IX
Semana 9
Atributos y dominios
Atributos
Tipos de Datos
Revisar los tipos de datos disponibles en el DBMS, en especial
- Número de dígitos en números enteros
- La precisión de los flotantes
- Cadenas de caracteres de longitud fija (char(50)) y variable (varchar (50))
- Blobs (Binary large objects) y Clobs (Character large objects)
Llaves primarias
En ocasiones se pueden presentar casos en donde la llave primaria no puede representarse en alguno de los tipos ofrecidos por el dbms, en ese caso se podría definir alguno y bien optar por otra llave primaria.
Importante:
Algunos dbms poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automáticamente manipular algún atributo para generar llaves incrementales. Pero es importante verificar: como se manejan internamente?, se pueden reiniciar ?, se permite especificar algún valor inicial ?
Orden de los atributos (columnas)
Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:
- Columnas de longitud fija que no se actualizan frecuentemente.
- Aquellas que nunca se actualizan que por lo general tendrán longitud variable.
- Las que se actualizan frecuentemente.
Integridad Referencial
- En la medida de lo posible indicar cuales columnas brindan o sirven de vínculo entre 2 tablas.
- El usuario (programador) puede hacerse cargo de esto pero es mejor que el dbms se haga cargo.
- No se recomienda en ambientes de desarrollo.
Indices
"Es una tabla que contiene una lista de elementos (llaves) y números de referencia donde dichos elementos se encuentran (campos de referencia)".
Un índice es un atajo desde un campo llave hacia la localización real de los datos.
Es el punto clave de la optimización de velocidad de toda base de datos.
Si se busca alguna tupla en base a un atributo que no tiene un índice entonces se realiza un escaneo de la tabla completa lo cual es demasiado costoso, por eso es recomendable usar índices en:
- Llaves primarias
- Llaves foráneas
- Indices de acceso
- Ordenamiento
SEMANA VIII
Semana 8
Teoría de recursividad
Consultas recursivas mediante expresiones de tabla comunes
Una expresión de tabla común (CTE) ofrece la gran ventaja de poder hacer referencia a sí misma, creando así una CTE recursiva. Una CTE recursiva es aquélla en la que una CTE inicial se ejecuta varias veces para devolver subconjuntos de datos hasta que se obtenga el conjunto de resultados completo.
Se considera que una consulta es recursiva cuando hace referencia a un CTE recursiva. La devolución de datos jerárquicos es un uso frecuente de las consultas recursivas; por ejemplo, mostrar los empleados en un organigrama o los datos en un escenario de lista de materiales en donde un producto primario tiene uno o varios componentes que, a su vez, tienen subcomponentes o son componentes de otros elementos primarios.
Una CTE recursiva puede simplificar en gran medida el código necesario para ejecutar una consulta recursiva en una instrucción SELECT, INSERT, UPDATE, DELETE o CREATE VIEW. En versiones anteriores de SQL Server, suele ser necesario que una consulta recursiva utilice tablas temporales, cursores y lógica para controlar el flujo de los pasos recursivos. Para obtener más información acerca de las expresiones de tabla comunes, vea Usar expresiones de tabla comunes.
La estructura de la CTE recursiva de Transact-SQL es similar a las rutinas de otros lenguajes de programación. Aunque las rutinas recursivas de otros lenguajes devuelven un valor escalar, una CTE recursiva puede devolver varias filas.
Una CTE recursiva se compone de tres elementos:
1. Invocación de la rutina.
La primera invocación de la CTE recursiva se compone de una o varias CTE_query_definitions combinadas mediante operadores UNION ALL, UNION, EXCEPT o INTERSECT. Como estas definiciones de consulta forman el conjunto de resultados base de la estructura de CTE, se hace referencia a ellas como miembros no recursivos.
CTE_query_definitions se consideran miembros no recursivos a no ser que hagan referencia a la propia CTE. Todas las definiciones de consulta de miembro no recursivo deben colocarse antes de la primera definición de miembro recursivo y debe utilizarse un operador UNION ALL para combinar el último miembro no recursivo con el primer miembro recursivo.
2. Invocación recursiva de la rutina.
La invocación recursiva incluye una o varias CTE_query_definitions combinadas mediante operadores UNION ALL que hagan referencia a la propia CTE. Estas definiciones de consulta se conocen como miembros recursivos.
3. Comprobación de finalización.
La comprobación de finalización es implícita; la recursividad se detiene cuando no se devuelven filas desde la invocación anterior.
SEMANA VII
Semana 7
Teoría de relaciones cardinalidad
GRADO Y CARDINALIDAD DE LAS RELACIONES.-
Se define grado de una relación como el número de entidades que participan en una relación. Las relaciones en las que participan dos entidades son binarias o de grado dos. Si participan tres serán ternarias o de grado 3. Los conjuntos de relaciones pueden tener cualquier grado, lo ideal es tener relaciones binarias.
La cardinalidad es el número de instancias o elementos de una entidad que pueden asociarse a un elemento de la otra entidad relacionada. La cardinalidad se representa mediante una pareja de datos (entre paréntesis y separados por una coma) indicando sus valores máximo y mínimo: (cardinalidad mínima, cardinalidad máxima).
Son posibles las siguientes cardinalidades:
(1,1) uno a uno
(1,n) uno a muchos
(n,1) muchos a uno
(m,n) muchos a muchos
El valor “0” se pone cuando la participación de la entidad es opcional, es decir no está obligada a participar en la relación: (0,n) , (0,1)
Ejemplo: ‘Un libro puede estar escrito por ninguno, uno o varios autores. Un autor escribe al menos un libro y puede escribir varios.’
Ejemplo: ‘Una persona puede tener o no tener un seguro, y un seguro es de 1 de una persona’
5.) RELACIONAR Y ANALIZAR LA CARDINALIDAD
Relacionar y analizar cardinalidad en las relaciones binarias propuestas.
PROCEDIMIENTO:
1.- Enlazar y colocar el nombre de la relación más apropiada
2.- Definir la cardinalidad a cada lado de la relación.
3.- Comentar en palabras el significado de la relación en cada sentido.
SEMANA VI
SEMANA 6
MODELO E/R (ENTIDAD - RELACION III)
Modelado Físico
El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como:
- Conocimiento a fondo de los tipos de objetos (elementos) soportados
- Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de datos, etc.
- Detalles y variaciones de las versiones
- Parámetros de configuración
- Data Definition Language (DDL)
Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que las entidades pasen a ser tablas (más las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas.
Físicamente esta metáfora de una tabla se mapea al medio físico, con algunas consideraciones como se menciona en las siguientes secciones.
Atributos
Tipos de Datos
Revisar los tipos de datos disponibles en el DBMS, en especial
- Número de dígitos en números enteros
- La precisión de los flotantes
- Cadenas de caracteres de longitud fija (char(50)) y variable (varchar (50))
- Blobs (Binary large objects) y Clobs (Character large objects)
Llaves primarias
En ocasiones se pueden presentar casos en donde la llave primaria no puede representarse en alguno de los tipos ofrecidos por el dbms, en ese caso se podría definir alguno y bien optar por otra llave primaria.
Importante:
Algunos dbms poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automáticamente manipular algún atributo para generar llaves incrementales. Pero es importante verificar: como se manejan internamente?, se pueden reiniciar ?, se permite especificar algún valor inicial ?
Orden de los atributos (columnas)
Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:
- Columnas de longitud fija que no se actualizan frecuentemente.
- Aquellas que nunca se actualizan que por lo general tendrán longitud variable.
- Las que se actualizan frecuentemente.
SEMANA V
SEMANA 5
BASE DE DATOS - Capitulo 2: Modelo
Entidad-Relación (E-R)
1.) DEFINICIÓN.-
Es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas.
Representa a la realidad a través de entidades, que son objetos que existen y se distinguen de otros por sus características, ejemplo: un alumno, se caracteriza por sus nombres, en una materia que domina, en su número de matrícula, etc. Estas entidades se encuentran relacionadas.
SEMANA IV
SEMANA 4
Modelado Entidad-Relación
El Modelo Entidad-Relación.
- Se elabora el diagrama (o diagramas) entidad-relación.
- Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:
- Transformación de relaciones múltiples en binarias.
- Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).
- Conversión en tablas (en caso de utilizar una base de datos relacional).
lunes, 10 de octubre de 2011
Semana1 BBDD.
Base de datos
Una base de datos o banco de datos (en ocasiones abreviada con la sigla BD o con la abreviatura b. d.) es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. Tipos de Base de Datos
Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto que se esté manejando, la utilidad de las mismas o las necesidades que satisfagan.
Según la variabilidad de los datos almacenados
Bases de datos estáticas
Son bases de datos de sólo lectura, utilizadas primordialmente para almacenar datos históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de datos a través del tiempo, realizar proyecciones y tomar decisiones.
Bases de datos dinámicas
Éstas son bases de datos donde la información almacenada se modifica con el tiempo, permitiendo operaciones como actualización, borrado y adición de datos, además de las operaciones fundamentales de consulta. Un ejemplo de esto puede ser la base de datos utilizada en un sistema de información de un supermercado, una farmacia, un videoclub o una empresa.
Según el contenido
Bases de datos bibliográficas
Sólo contienen un subrogante (representante) de la fuente primaria, que permite localizarla. Un registro típico de una base de datos bibliográfica contiene información sobre el autor, fecha de publicación, editorial, título, edición, de una determinada publicación, etc. Puede contener un resumen o extracto de la publicación original, pero nunca el texto completo, porque si no, estaríamos en presencia de una base de datos a texto completo (o de fuentes primarias —ver más abajo). Como su nombre lo indica, el contenido son cifras o números. Por ejemplo, una colección de resultados de análisis de laboratorio, entre otras.
Bases de datos de texto completo
Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas las ediciones de una colección de revistas científicas.
Directorios
Un ejemplo son las guías telefónicas en formato electrónico.
Bases de datos o "bibliotecas" de información química o biológica
Son bases de datos que almacenan diferentes tipos de información proveniente de la química, las ciencias de la vida o médicas. Se pueden considerar en varios subtipos:
- Las que almacenan secuencias de nucleótidos o proteínas.
- Las bases de datos de rutas metabólicas.
- Bases de datos de estructura, comprende los registros de datos experimentales sobre estructuras 3D de biomoléculas-
- Bases de datos clínicas.
- Bases de datos bibliográficas (biológicas, químicas, médicas y de otros campos): PubChem, Medline, EBSCOhost.
Modelos de bases de datos
Además de la clasificación por la función de las bases de datos, éstas también se pueden clasificar de acuerdo a su modelo de administración de datos.
Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de datos (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos.
Algunos modelos con frecuencia utilizados en las bases de datos:
Bases de datos jerárquicas
Artículo principal: Base de datos jerárquica
Éstas son bases de datos que, como su nombre indica, almacenan su información en una estructura jerárquica. En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas.
Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento.
Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.
Suscribirse a:
Entradas (Atom)