Главная страница
Навигация по странице:

  • Задачи изучения дисциплины.

  • БД_КОНСПЕКТ. Введение. Цели и задачи. Изучение базы и банков данных 1 Реляционные базы данных 3 Реляционная база данных 6


    Скачать 0.57 Mb.
    НазваниеВведение. Цели и задачи. Изучение базы и банков данных 1 Реляционные базы данных 3 Реляционная база данных 6
    АнкорБД_КОНСПЕКТ.doc
    Дата19.05.2017
    Размер0.57 Mb.
    Формат файлаdoc
    Имя файлаБД_КОНСПЕКТ.doc
    ТипДокументы
    #9546
    страница1 из 22
      1   2   3   4   5   6   7   8   9   ...   22

    Введение. Цели и задачи. Изучение базы и банков данных 1

    Реляционные базы данных 3

    Реляционная база данных 6

    Функции СУБД. Типовая организация СУБД 7

    Типовая организация СУБД 9

    Базисные средства манипулирования реляционными данными 10

    Реляционная алгебра 11

    Общая интерпретация реляционных операций 12

    Особенности теоретико-множественных операций реляционной алгебры 12

    Реляционное исчисление 13

    Целостность сущности и ссылок 14

    СУБД в архитектуре клиент-сервер 15

    Сервера баз данных 18

    Типичные распределения функций между клиентами и серверами 19

    Оптимизация запросов 22

    Стадии процесса оптимизации запросов 23

    Язык реляционных баз данных SQL 25

    Типы данных 28

    Управляющие конструкции Transact SQL 31

    Логические операторы 33

    Создание, модификация и удаление таблиц 34

    Определение идентификационной колонки (Identity) 34

    Создание таблиц средствами TRANSACT SQL 35

    Изменение структуры таблицы при помощи Transact-SQL 37

    Управление данными 40

    Использование INSERT 40

    Извлечение данных 42

    Изменение данных 46

    Хранимые процедуры 47

    Создание хранимых процедур 49

    Управление процессом компиляции хранимой процедуры 50

    Управление автоматическим выполнением хранимых процедур 51

    Модификация хранимой процедуры 52

    Удаление хранимых процедур 52

    Использование индексов 53

    Создание индексов 56

    Использование представлений 57

    Создание триггеров 58

    Использование курсора 61

    Управление правами доступа к объектам базы данных 62

    Современные направления исследований и разработок 65

    Введение. Цели и задачи. Изучение базы и банков данных


    Цель изучения дисциплины базы и банки данных – это обучение студентов принципам построения баз данных, возможностям их применения и проектирования как составных элементов функциональных систем, автоматизированных систем обработки информации.

    Задачи изучения дисциплины. В процессе обучения главной задачей студента является понять принципы организации информационных систем на основе систем управления базами данных (СУБД).

    Студент должен иметь представление:

    1. об уровнях абстракции данных и языковых средствах СУБД;

    2. о принципах инфологического и датологического проектирования баз данных.

    В результате изучения дисциплины “Базы и банки данных” студент должен знать реляционную модель данных, реляционные исчисления и реляционную алгебру, язык баз данных SQL.

    1. методы отображения инфологической схемы на модели данных.

    Студент должен владеть методами и средствами организации распределенной обработки данных.

    Студент должен уметь использовать современные СУБД, а также языки описания и манипулирования данными.

    Студент должен получить опыт проектирования баз данных и администрирования СУБД.

    Реляционные базы данных


    За историю развития баз данных было разработано множество способов хранения, структуризации и обработки информации. По технологии обработки базы данных подразделяют следующим образом:

    1. Распределенная база данных – этот способ обработки требует использования нескольких серверов, на которых может храниться пересекающаяся или даже дублирующаяся информация. Для работы с такой базой данных используется система управления распределенными базами данных.

    2. Централизованная база данных – при таком способе обработки база данных располагается на одном компьютере. Если для этого компьютера установлена поддержка сети, то множество пользователей с клиентских компьютеров могут одновременно обращаться к информации хранящейся в центральной базе данных.

    Система централизованных баз данных с сетевым доступом имеет различные архитектуры:

    – файл-сервер;

    Эта архитектура предполагает использование выделенного компьютера в качестве сервера файла. На этом сервере хранятся файлы баз данных, которые по запросу пользователей копируются на их локальные компьютеры, там и производится вся основная обработка данных. После того как пользователи выполняют необходимые изменения данных, они копируют файл обратно на файл-сервер, где другие пользователи могут снова их использовать. Кроме того, каждый пользователь может создавать на своем компьютере свои собственные базы данных, которые используются монопольно. При использовании архитектуры файл-сервер производительность системы резко падает с ростом числа пользователей.

    – клиент-сервер.

    При использовании этой архитектуры выделенный компьютер используется не только в качестве хранилища файлов, но и выполняет основной объем действий по обработке информации. Пользователь рабочей станции отправляет список операций обрабатываемых данных (запрос), которые необходимо выполнить центральному компьютеру, т. е. серверу. Сервер выполняет необходимые вычисления и выборку данных и отправляет готовый результат клиенту. Для описания запросов часто используют структурированный язык запросов SQL (Structured Query Language). Этот язык специально разработан для создания запросов.

    Помимо подразделения баз данных по методам обработки информации их можно классифицировать по использованной модели (структуре) данных. Модель данных включает в себя структуры данных, операции их обработки и ограничение целостности. С помощью модели данных можно наглядно представить структуру объектов и установленные между ними связи. В терминологии модели данных используются понятия элемент данных и правило связывания. Элемент данных описывает любой набор данных, а правило связывания определяет алгоритмы взаимосвязи элементов данных.

    К настоящему времени разработано множество различных моделей данных. На практике используются три основных.

    1. Иерархическая модель данных.

    Иерархическая модель данных имеет иерархическую структуру, т.е. каждый из элементов связан только с одним вышестоящим элементом, в то же время на него могут ссылаться один или несколько нижестоящих элементов. В терминологии иерархической модели используются понятия “элемент”, “уровень” и “связь”. Элемент (узел) чаще всего представляет собой набор атрибутов, описывающих некоторый объект, хотя в общем случае это может быть любой набор данных, имеющих какой-то ключевой атрибут.

    Иерархическая модель схематично изображается в виде дерева. Эта модель представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое дерево. Иерархическое дерево имеет единственную вершину, неподчиненную никакой другой вершине и находящуюся на самом верхнем уровне (IBM).

    Достоинства иерархической модели данных:

    ─ простота модели (иерархия баз данных при использовании иерархической модели напоминает структуру компании или генеалогическое дерево);

    ─ использование отношений предок-потомок;

    ─ быстродействие.

    В СУБД, реализованной на основе иерархической модели данных, отношение предок-потомок реализуется в виде физических указателей из одной записи на другую, вследствие чего перемещение по базе данных происходит очень быстро. Иерархические модели данных идеально подходят для большого числа транзакций (управление банкоматами, проверка номеров кредитных карт).

    2. Сетевая модель данных.

    Эта модель использует ту же терминологию, что и иерархическая модель. Единственное различие между иерархической и сетевой моделями заключается в том, что в сетевой модели каждый элемент данных может быть связан с любым другим элементом. Если структура данных оказывается сложнее, чем традиционная иерархия, простота организации иерархической базы данных становится ее существенным недостатком.

    3. Реляционная модель данных.

    Основная идея реляционной модели данных заключается в том, чтобы представить любой набор данных в виде двумерной таблицы. В простейшем случае реляционная модель данных описывает единственную двумерную таблицу, но чаще всего эта модель описывает структуру и взаимоотношения между несколькими различными таблицами.

    Развитие реляционных баз данных началось в 60-х гг., когда появились первые работы, в которых обсуждались возможности использования при проектировании баз данных привычных и естественных способов представления данных так называемых табличных датологических моделей.

    Теория реляционных баз данных, разработанная в 70-х гг. в США доктором Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Коддом теоретическая база стала основой для разработки теории проектирования баз данных. Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Кодд доказал, что любой набор данных можно представить в виде двумерных таблиц особого вида известных в математике как отношения. От английского слова relation произошло название «реляционная модель данных». Термин «отношение реляционной модели данных» обозначает таблицу. Наименьшая единица данных, которой оперирует реляционная модель данных, – это отдельное атомарное для данной предметной области значение данных, которое не может быть разложено на более простые составляющие. Так в одной предметной области составляющие адреса могут рассматриваться как различные значения, а в другой как единое целое. Множество атомарных значений одного и того же типа образуют домен. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементам данных. В простейшем случае домен определяется как допустимое потенциальное множество значений одного типа. Например, совокупность дат рождений всех сотрудников составляет домен дат рождения, а имена – домен имен сотрудников. Домен дат рождений имеет тип данных, позволяющий хранить информацию о моментах времени, а домен имен сотрудников должен иметь символьный тип данных.

    В один домен могут входить значения из нескольких колонок, объединенных помимо одинакового типа данных еще и логически. Если два значения берутся из одного и того же домена, то можно выполнить сравнение этих двух значений. В большинстве систем управления реляционных баз данных понятие домена не реализовано.

    Каждый элемент данных в отношении может быть определен с указанием его адреса в формате А[i, j], где А – элемент данных, i – строка отношения, j – номер атрибута отношения. Количество атрибутов в отношении определяет его порядок. Множество значений А[i, j] при постоянном i и всех возможных j образуют кортеж или просто строку таблицы. Количество всех кортежей в отношении определяет его мощность или кардинальное число. Мощность отношения в отличие от порядка отношения может со временем меняться. Совокупность всех кортежей образует тело отношения или таблицу. Поскольку отношения являются математическими множествами, которые по определению не могут содержать совпадающих элементов, никакие два кортежа в отношении не могут быть дубликатами друг друга в любой момент времени.

    Некоторое множество атрибутов образуют ключ для данного отношения, если задание значений этих атрибутов однозначно определяют значение все атрибутов в таблице. Множество атрибутов отношения является возможным ключом этого отношения тогда и только тогда, когда выполняются два независимых от времени условия:

    1) уникальность – в каждый момент времени никакие два различные кортежа отношения не имеют одинакового значения для комбинации входящих в ключ атрибутов, т.е. в таблице не может быть двух строк, имеющих одинаковый ключ;

    2) минимальность – ни один из не входящих в ключ атрибутов не может быть исключен из ключа без нарушения уникальности.

    Каждое отношение имеет, по крайней мере, один возможный ключ. Это следует из самого определения отношения.
      1   2   3   4   5   6   7   8   9   ...   22
    написать администратору сайта