Сделай Сам Свою Работу на 5

Схема отношения, схема базы данных





Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) - это набор именованных схем отношений.

Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.



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

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



Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

4. Базовый язык СУБД и навигация в БД.

 

5. Реляционная алгебра на примере SQL.

Рассмотрим, как связаны операции реляционной алгебры и язык SQL, т.е. приведем примеры запросов SQL, аналогичных операциям реляционной алгебры. В качестве примера базы данных будем использовать "Музыкальные файлы".
Операция проекции proj выражается через SELECT с ключевым словом DISTINCT.
Получить все названия ансамблей
proj НазАнс (Ансамбли)

SELECT DISTINCT НазАнс FROM Ансамбли

Операция выбора sel выражается через SELECT с ключевым словом WHERE.
Получить данные об ансамблях из России
sel СтрАнс='Россия' (Ансамбли)

SELECT * FROM Ансамбли WHERE СтрАнс='Россия'

Условия также могут быть и сложными. Получить имена музыкантов, родившихся в 20-м веке

SELECT ИмяМуз FROM Музыканты WHERE ДатаРожд>'31.12.1899' AND ДатаРожд<'01.01.2001'

В заключение данного раздела отметим, что существует альтернативный подход манипулирования реляционными данными, основанный на математической логике (точнее, на исчислении предикатов первого порядка), - реляционное исчисление. Принципиальное различие между ними следующее: алгебра представляет набор операторов, с помощью которых из определенных отношений можно построить необходимое отношение; в то время как исчисление представляет собой просто систему обозначений для определения необходимого отношения в терминах данных отношений. Пользователь в терминах реляционного исчисления лишь устанавливает определенные характеристики необходимого отношения, оставляя системе решать, что соединять, проецировать и т.д., чтобы получить требуемый результат. Таким образом, формулировка запроса в терминах исчисления носит описательный характер, а алгебраическая формулировка – предписывающий.



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

 

6. Нереляционные базы данных.

Пользователь реляционной системы видит данные, представленные в виде таблиц и никак иначе.

Пользователь нереляционной системы, напротив, видит данные, представленные в других структурах и операциях.

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

Реляционная база данных представляет собой множество взаимосвязанных таблиц. В каждой таблице хранится информация об объектах определенного типа. Между таблицами установлены отношения. Собственно именно поэтому база данных и называется реляционной.

relation в переводе с английского "отношение".

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

Есть еще сетевые базы данных. Но это так сказать частный случай иерархической системы.

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

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

Поэтому используется реляционная база данных. Она понятна, проста и удобна для реализации.

7. Проектирование баз данных.

Одной из наиболее трудоемких и сложных задач при создании ин­формационных систем является проектирование Базы данных, как ос­новы подсистемы представления и обработки данных. Организация данных требует предварительного моделирова­ния предметной области, т. е. построения инфологической модели дан­ных, главным назначением которой является систематизация разнооб­разной информации и отра­жение ее свойств по содержанию, структуре, объему, связям, динамике с учетом удовлетворения информационных потребностей всех катего­рий пользователей.

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

База данных рассматривается как совокупность моделей данных, описывающих логическую структуру и физическую организацию данных на машинных носителях, находящихся под управлением СУБД. Проек­тирование состоит в построении комплекса взаимосвязан­ных моделей данных. На рис. 6.2 условно отображены этапы процесса проектиро­вания Базы данных.

Процесс проектирования Базы данных начинается с постановки за­дачи и выявления объектов, процессов или сущностей предметной об­ласти. Например, объектами могут быть предприятия, вкладчики, банки. Для каждого из объектов выбирается набор характеризующих его свойств (полей, реквизитов). Для предприятия – наименование, адрес, расчетный счет, название банка и пр., для вкладчика – фамилия, имя, отчество, адрес, паспортные данные, место работы и пр. Затем в про­цессе анализа определяется информационная потреб­ность каждой за­дачи, которую составляют входные и результатные до­кументы, и опре­деляется периодичность решения задач.

Работа проектировщиков Базы данных в значительной степени зави­сит от качества инфологической модели. Инфологическая модель соз­дается для того, чтобы на ее основе можно было построить модель дан­ных, т. е. она должна учитывать особенности реализации выбранной СУБД. На основе инфологической модели строятся концептуаль­ная, ло­гическая и физическая модели. Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информаци­онной системы.

Концептуальное проектирование – сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприя­тия:

· обследование предметной области, изучение ее информационной структуры;

· выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами, свя­зями между ними и процессами;

· моделирование и интеграция всех представлений.

Результат данного этапа – концептуальная модель, ин­вариантная к структуре Базы данных, часто представляется в виде модели «сущ­ность-связь».

Логическое проектирование – преобразование требований к данным в структуры данных. Результат – СУБД-ориентированная структура Базы данных и спецификации прикладных программ. На этом этапе часто мо­делируют Базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.

Физическое проектирование – определение особенностей хранения данных, методов доступа и т. д.

Различие уровней представления данных на каждом этапе проекти­рования представлено в табл. 6.1.

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

Таблица 6.1

Различие уровней представления данных

Уровень представления данных Вид представления данных
Концептуальный уровень: сущности, атрибуты, связи Представление аналитика
Логический уровень: записи, элементы данных, связи между записями Представление программиста
Физический уровень: группировка данных, индексы, методы доступа Представление администратора

Проектирование Базы данных имеет свои особенности на всех ста­диях и этапах проектирования.

I этап. Подготовка Технического задания (постановка задачи). Включает сбор материалов в процессе обследования и оформление Технического за­дания. Выполняется следующий комплекс работ:

· определение экономической целесообразности и технической воз­можности создания Базы данных;

· выявление состава, содержания и характеристик хранимой информа­ции на основе результатов обследования предметной области;

· определение оценок, количественных характеристик информацион­ных объектов и структурных связей между ними на основе результатов анализа информационных потребностей приложений;

· построение инфологической (информационно-логической) модели предметной области, определяющей совокупность информационных объектов, их атрибутов и структурных связей, динамику их изменения и характеристику информационных потребностей пользователя;

· предварительная оценка вариантов разработки Базы данных;

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

По результатам выполнения этапа создаются Технико-экономическое обоснование проектирования Базы данных (ТЭО) и Техническое зада­ние (ТЗ).

II этап. Технический проект. Результаты разработок и про­ектных решений оформляются в виде технического проекта. На данном этапе выполняются следующие работы:

· составление и уточнение инфологической модели;

· логическое проектирование (составление концептуальной схемы);

· физическое проектирование (распределение по уровням памяти, вы­бор методов доступа, определение размеров файлов и т. д.);

· проектирование и представление данных для приложений;

· проектирование программного обеспечения, включая СУБД.

III этап. Рабочий проект. Детализуются решения техниче­ского проекта. Выполняется следующий комплекс работ:

· разработка программных средств и сервисных программ;

· настройка СУБД и приложений в соответствии с выбранными пара­метрами;

· разработка контрольного примера;

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

IV этап. Внедрение проекта (эксплуатация и отладка). Выполнятся проверка проектных реше­ний и их доводка, при необходимости дорабатывается технология ра­боты с Базой данных, пользователями, выполняется перераспределе­ние обязанностей, устанавливаются категории и иерархия доступа поль­зователя к данным.

8. Проектирование концептуальной модели БД.

Концептуальное проектирование – сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприя­тия:

· обследование предметной области, изучение ее информационной структуры;

· выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами, свя­зями между ними и процессами;

· моделирование и интеграция всех представлений.

Результат данного этапа – концептуальная модель, ин­вариантная к структуре Базы данных, часто представляется в виде модели «сущ­ность-связь».

9. Проектирование логической модели БД.

Логическое проектирование – преобразование требований к данным в структуры данных. Результат – СУБД-ориентированная структура Базы данных и спецификации прикладных программ. На этом этапе часто мо­делируют Базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.

Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм.

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

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

10.Методика реализации БД

Исходной информацией для создания приложения является предприятие или его фрагмент, который задан в качестве описания объекта автоматизации для выполнения КП. Основными исходными данными для разработки БД является:

1. Требования к БД, которые определены в ТЗ;

2. Документы или та информация об объекте, которые должны храниться в БД. В идеальном случае вся информация должна храниться в БД или формироваться на ее основе;

3. Задачи, которые необходимо реализовать в рамках приложения. В общем случае задачи обычно накладывают некоторые ограничения на перечень хранимой БД, информации. Это вызвано тем, что задачи для автоматизации только частично охватывают существующие в объекте документы.

Процессы реализации БД включают 4 группы объектов:

1. Процесс «Определение и анализ требования к БД»;

2. Процессы проектирования БД;

3. Процессы создания БД;

4. Процесс проверки БД.

Рисунок 2.1 – Процессы реализации БД

 

11. Доступ к БД в архитектуре «клиент-сервер»

Использование технологии " клиент – сервер " предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети).

Так, архитектура " клиент – сервер " разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Language), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер – специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами [ [ 3.2 ] , [ 3.3 ] ]. Архитектура системы представлена на рис. 3.3.

Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БДизменений, закончившихся аварийно [ [ 3.2 ] , [ 3.3 ] ].

 

 

12. Доступ к БД через интернет

В традиционной архитектуре клиент/сервер [1] действует принцип разделения задач, когда используется более чем один компьютер, и каждый из них выполняет строго определенные ему задачи. Такой подход уменьшает загрузку каждого узла системы, позволяя ему сконцентрироваться на выполнении ⌠своих■ задач и, следовательно, увеличивает производительность и возможности системы в целом.

В СУБД Oracle система баз данных разделена на две части: клиентскую часть и серверную часть [7] (Рис. 1).

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

Серверная часть, работающая на программном обеспечении Oracle, обслуживает задачи, необходимые для параллельного общего доступа к данным. Серверная часть принимает и обрабатывает SQL и PL/SQL запросы, посылаемые клиентскими приложениями [13]. Компьютер, обслуживающий серверную часть, должен быть оптимизирован для решения своих специфических задач √ он должен иметь большую дисковую память и быстрый процессор [8].

Связь между сервером и клиентом осуществляется посредством SQL*Net √ сетевого интерфейса Oracle [9]. SQL*Net позволяет программам Oracle, запущенным на сетевых клиентских рабочих станциях и серверах, организовать доступ, модификацию, разделение и хранение данных на других серверах.

При построении Web-интерфейсов к базам данных различают два подхода: доступ к базе данных на стороне клиента, и доступ к базе данных на стороне сервера.

 

 








Не нашли, что искали? Воспользуйтесь поиском по сайту:



©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.