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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


контрольная работа Архитектура субд. Реляционная модель данных

Информация:

Тип работы: контрольная работа. Добавлен: 12.06.2012. Сдан: 2011. Страниц: 9. Уникальность по antiplagiat.ru: < 30%

Описание (план):


АРХИТЕКТУРА СУБД. РЕЛЯЦИОННАЯ  МОДЕЛЬ ДАННЫХ  

      1.      Понятие базы данных.
      2.      Трехуровневая архитектура базы данных.
      3.      Жизненный цикл базы данных.
      4.      Архитектура СУБД.
      5.      Реляционная модель данных.
      6.      Проектирование реляционных баз данных.
      7.      Нормальные формы отношений.
      8.      Реляционная алгебра.     
       
       

1. Понятие базы данных.
   Система с базой данных – это любая  информационная система на базе компьютера, в которой данные могут совместно  использоваться многими приложениями.
    Информационная  система – автоматическая система, организующая данные и выдающая информацию.
    Информационно-управляющая  система – система, обеспечивающая информационную поддержку менеджмента.
    Данные – разрозненные факты.
    Информация – организованные и обработанные данные.
    Под базой данных понимается множество взаимосвязанных элементарных групп данных (информации), которые могут обрабатываться одной или несколькими прикладными системами. Система базы данных состоит из базы данных; программного обеспечения общего назначения, которая называется системой управления базой данных (СУБД), и служит для управления базой данных; соответствующего оборудования и людей.            
Каждая СУБД должна удовлетворять следующим  требованиям:
·   обеспечивать пользователю возможность создавать новые БД и определять их схему (логическую структуру данных) с помощью специального языка — языка определения данных; поддерживать разнообразные представления одних и тех же данных;
·   позволять «запрашивать» данные и изменять их с помощью языка запросов, или языка манипулирования данными; допускать интеграцию и совместное использование данных различными приложениями;
·   поддерживать хранение очень больших массивов данных, измеряемых гигабайтами и более, в течение долгого времени, защищая их от случайной порчи и неавторизованного использования, а также — обеспечивать модификацию БД и доступ к данным путем запросов, т.е. гарантировать безопасность и целостность данных;
·   контролировать доступ к данным одновременно для многих пользователей; исключать влияние запроса одного пользователя на запрос другого и не допускать одновременный доступ, который может испортить данные, т.е. гарантировать управление параллельным доступом к данным.   
    Система с базой данных состоит из следующих  компонентов:
·   Пользователи, т.е. люди, которые используют данные.
·   Приложения, т.е. программы пользователей, которым требуются данные из системы.
·   СУБД – программное обеспечение, которое управляет доступом к данным и обеспечивает указанные функциональные возможности системы с базой данных.
·   Данные, т.е. строки, хранящиеся в файлах.
·   Система-хост – компьютерная система, в которой хранятся файлы. Доступ к строкам данных осуществляется системой-хостом. Роль СУБД состоит в том, чтобы генерировать запросы, позволяющие использовать функциональные возможности системы управления файлами системы-хоста для обслуживания различных приложений. СУБД – это дополнительный уровень программного обеспечения, надстроенный над программным обеспечением системы-хоста.            
Таким образом, систему с БД можно представить  в виде следующей последовательности уровней:  

                              

На самом  нижнем уровне находятся данные, хранящиеся в физических файлах (физическая память БД). На верхнем уровне – приложений с их собственными представлениями  одних и тех же физических данных. Каждой представление БД – это  определенная логическая структура, построенная  из лежащих в основе физических данных. Чтобы обеспечить интерфейс между  физической памятью БД и ее разнообразными логическими версиями (множеством поддерживаемых представлений) СУБД, в свою очередь  должна состоять из нескольких уровней.   

2. Трехуровневая архитектура базы данных.
Различие  между логическим и физическим представлением данных официально признано в 1978 году, когда комитет ANSI/SPARC предложил обобщенную структуру систем баз данных. Эта структура получила название трехуровневой архитектуры. Три уровня архитектуры следующие: внутренний, концептуальный и внешний.            
Внутренний  уровень – это уровень, определяющий физический вид базы данных, наиболее близкий к физическому хранению и связан со способами сохранения информации на физических устройствах хранения. С данным уровнем связаны дисководы, физические адреса, индексы, указатели и т.д. За этот уровень отвечают проектировщики физической БД, которые решают, какие физические устройства будут хранить данные, какие методы доступа будут использоваться для извлечения и обновления данных и какие меры следует принять для поддержания или повышения быстродействия системы управления базами данных. Пользователи не касаются этого уровня.            
Концептуальный  уровень – структурный уровень, определяющий логическую схему базы данных. На данном уровне выполняется концептуальное проектирование базы данных, которое включает анализ  информационных потребностей пользователей и определение нужных им элементов данных. Результатом концептуального проектирования является концептуальная схема, логическое описание всех элементов данных и отношений между ними.            
Внешний уровень – структурный уровень БД, определяющий пользовательские представления данных. Каждая пользовательская группа получает свое собственное представление данных в БД. Каждое такое представление данных дает ориентированное на пользователя описание элементов данных, из которых состоит представление данных, и отношений между ними. Его можно напрямую вывести из концептуальной схемы. Совокупность таких пользовательских представлений данных и дает внешний уровень.  
 
 
 

Представления пользователей и приложений  
 
    Внешний уровень
Отображения
   
Концептуальная  схема
Концептуальный  уровень
   
Отображение
Внутренний  уровень
 
Система-хост
Хранящиеся  данные
    
Рис. Уровни СУБД  

3. Жизненный цикл базы данных. 
     Процесс проектирования, реализации и  поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД).Процедура создания системы называется жизненным циклом системы (ЖЦС).            
Понимание и правильный подход к ЖЦБД очень  важен и требует детального рассмотрения, так как в его основе лежит  подход,ориентированный на данные. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.            
ЖЦБД состоит  из следующих этапов:            
1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:
·   какие прикладные программы используются, и какие функции они выполняют;
·   какие файлы связаны с каждым из этих приложений;
·   какие новые приложения и файлы находятся в процессе работы.            
Данная информация помогает определить, как используется информация приложений, определить будущие  требования к системе БД.            
Информация  этого этапа документируется  в виде обобщенной модели данных.            
2. Проверка осуществимостиЗдесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:
·   технологическая осуществимость – есть ли технология для реализации запланированной БД?
·   операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?
·   экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?            
3. Определение требований включает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах:
·   Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.
·   Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.);фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.
·   Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения.
·   Разработка плана поэтапного создания системы, включающий выбор исходных приложений.            
4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.            
Основным  выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.            
5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.            
1) Выбор и приобретение необходимой СУБД.            
2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:
·   на основе инфологической модели данных строится схема данных для конкретной СУБД, при необходимости реализуется денормализация БД с целью ускорения обработки запросов во всех критичных по времени приложениях;
·   определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;
·   реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;
·   спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;
·   разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;
·   определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа.
·   разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).            
3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.            
4) Заполнение базы данных.            
5) Создание прикладных программ, контроль управления.             
6) Обучение пользователей.
    6. Оценка и усовершенствование схемы БД. Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.            
Таким образом, ЖЦБД включает в себя:
·   Изучение предметной области и представление соответствующей документации (1-3).
·   Построение инфологической модели (4).
·   Реализация (5).
·   Оценка работы и поддержка БД (6).  

4. Архитектура СУБД.    
 
 

 
 
     
Рис. Главные компоненты СУБД             
 

Данные, метаданные — содержат не только данные, но и информацию о структуре данных (метаданные). В реляционной СУБД метаданные включают в себя системные таблицы (отношения), имена отношений, имена атрибутов этих отношений и типы данных этих атрибутов.             
Часто СУБД поддерживает индексы данных. Индекс — это структура данных, которая помогает быстро найти элементы данных при наличии части их значения (например, индекс, который находит кортежи конкретного отношения, имеющие заданное значение одного из атрибутов). Индексы — часть хранимых данных, а описания, указывающие, какие атрибуты имеют индексы — часть метаданных.            
Менеджер  памяти —  получает требуемую информацию из места хранения данных и изменяет в нем информацию по требованию расположенных выше уровней системы.            
В простых  системах БД менеджером памяти может  служить система файлов операционной системы. Однако для повышения эффективности, СУБД обычно осуществляет прямой контроль памяти. Менеджер памяти состоит из двух компонентов:
·   Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки — смежные области памяти, содержащие от 4000 до 16000 байт).
·   Менеджер буфера управляет основной памятью. Он получает блоки данных с диска через менеджер файлов и выбирает страницу основной памяти для хранения конкретного блока. Он может временно сохранять дисковый блок в основной памяти, но возвращает его на диск, когда страница основной памяти нужна для другого блока. Страницы также возвращаются на диск по требованию менеджера транзакций.            
Процессор «запроса» — обрабатывает запросы и запрашивает изменения данных или метаданных. Он предлагает лучший способ выполнения необходимой операции и выдает соответствующие команды менеджеру памяти.            
Процессор (менеджер) запросов превращает запрос или действие с БД, которые могут  быть выполнены на очень высоком  уровне (например, в виде запроса SQL), в последовательность запросов на хранимые данные типа отдельных кортежей отношения или частей индекса на отношении. Часто самой трудной частью обработки запроса является его организация, т. е. выбор хорошего плана запроса или последовательности запросов к системе памяти, отвечающей на запрос.             
Менеджер  транзакций — отвечает за целостность системы и должен обеспечить одновременную обработку многих запросов, отсутствие интерференции запросов (сложение, min, max) и защиту данных в случае выхода системы из строя. Он взаимодействует с менеджером запросов, т. к. должен знать, на какие данные воздействуют текущие запросы (для избежания конфликтных ситуаций), и может отложить некоторые запросы и операции для избежания конфликтов. Менеджер транзакций взаимодействует также с менеджером памяти, т. к. схемы защиты данных обычно включают в себя хранение файла регистрации изменений данных. При правильном порядке выполнения операции файл регистрации будет содержать запись изменений, поэтому можно заново выполнить даже те изменения, которые не достигли диска из-за сбоя в системе.             
Типичные  СУБД позволяют пользователю сгруппировать  несколько запросов и/или изменений  в одной транзакции. Транзакция — это группа операций, которые необходимо выполнить последовательно, как одно целое.             
Как правило, система БД поддерживает одновременно множество транзакций. Именно правильное выполнение всех таких транзакций и  обеспечивает менеджер транзакций. Правильное выполнение транзакций обеспечивается ACID-свойствами (atomicity, consistency, isolation,durability):
·   атомарность — выполнение либо всех транзакций, либо ни одной из них (например, изъятие денег из банкомата и внесение соответственного дебета в счет клиента должны быть единственной атомарной транзакцией, не допускается выполнение каждой из этих операций по отдельности);
·   непротиворечивость — состояние, при котором данные соответствуют всем возможным ожиданиям (например, условие непротиворечивости для БД авиационных линий состоит в том, что ни одно из мест в самолете не бронируется для двух пассажиров);
·   изоляция — при параллельном выполнении двух или более транзакций их результаты должны быть изолированы друг от друга. Одновременное выполнение двух транзакций одновременно не должно привести к результату, которого не было бы, если они выполнялись последовательно (например, при продаже билетов на один и тот же рейс в случае свободного последнего места при одновременном запросе двух агентов, запрос одного должен быть выполнен, другого — нет);
·   долговременность — после завершения транзакции результат не должен быть  утрачен в случае сбоя системы, даже если этот сбой происходит сразу после завершения транзакции.            
Рассмотрим  также 3 типа обращения к СУБД:
1.                  Запросы — вопросы по поводу данных могут генерироваться двумя способами:
    a)     с помощью общего интерфейса запросов (например, реляционная СУБД допускает запросы SQL, которые передаются процессору запросов, а также получает ответы на них);
    б) с помощью интерфейсов прикладных программ — запросы передаются через специальный интерфейс (через этот интерфейс нельзя передавать произвольные запросы);
2.                  Модификации — это операции по изменению данных. Они также могут выполняться либо с помощью общего интерфейса, либо через интерфейс прикладной программы;
3.                  Модификации схемы — это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.            
Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер: один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.             
В простейшей архитектуре клиент/сервер вся СУБД является сервером, за исключением  интерфейсов запроса, которые взаимодействуют  с пользователем и посылают запросы  или другие команды на сервер. Например, реляционная СУБД часто использует языкSQL для представления запросов от клиента к серверу. Затем сервер БД предоставляет клиенту ответ в виде таблицы (отношения). Существует тенденция увеличения нагрузки на клиента, т. к. при наличии множества одновременно работающих пользователей БД с сервером могут возникнуть проблемы.   

5. Реляционная модель данных.
     РМД некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений  позволяет хранить данные об объектах предметной области и моделировать связи между ними.            
Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Математически под N-арным отношением Rпонимают множество декартова произведения D1  D2  …  Dмножеств (доменов) D1, D2, …, D( ), необязательно различных:
 
D1
 
D2
 … 
Dn,

где D1  D2  …  D– полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.            
Домен - это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:
·   Домен имеет уникальное имя (в пределах базы данных).
·   Домен определен на некотором простом типе данных или на другом домене.
·   Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
·   Домен несет определенную смысловую нагрузку.            
Атрибут отношения есть пара вида <Имя_атрибута : Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.            
Отношение R, определенное на множестве доменов, содержит две части: заголовок и тело.            
Заголовок отношения – это фиксированное количество атрибутов отношения:

Заголовок отношения описывает декартово  произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой  данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).            
Тело  отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута : Значение_атрибута>:  

 
 

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

,

или короче
,

или просто
.            

Число атрибутов  в отношении называют степенью (или -арностью) отношения. Мощность множества кортежей отношения называютмощностью отношения.             
Схемой  отношения называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

Если атрибуты принимают значения из одного и того же домена, то они называются  -сравнимыми, где   – множество допустимых операций сравнений, заданных для данного домена. Например, если домен содержит числовые данные, то для него допустимы все операции сравнения, тогда  . Однако, и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он имеет также полный спектр операций сравнения.            
Схемы двух отношений называются эквивалентными, если они имеют одинаковую степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного домена:             
Пусть   – схема отношения   – схема отношения   после упорядочения имен атрибутов. Тогда
~
            

Таким образом, для эквивалентных отношений  выполняются следующие условия:
·   Таблицы имеют одинаковое количество столбцов.
·   Таблицы содержат столбцы с одинаковыми наименованиями.
·   Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.
·   Таблицы имеют одинаковые строки с учетом того, что порядок столбцов может различаться.            
Все такие  таблицы есть различные изображения одного и того же отношения.            
Свойства  отношений. Свойства отношений непосредственно следуют из приведенного выше определения отношения. В этих свойствах в основном и состоят различия между отношениями и таблицами.
·   В отношении нет одинаковых кортежей.
·   Кортежи не упорядочены (сверху вниз).
·   Атрибуты не упорядочены (слева направо).
·   Все значения атрибутов атомарны 

 
 

Рис. Схематическое изображение  отношения              

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


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.