Модели данных, поддерживаемые СУБД. Концепция и разработка распределенных СУБД
Принципы построения СУБД, их достоинства. Архитектура распределенной информационной системы. Разработка интернет-магазина рынка книг: построение физической модели данных на языке SQL, проектирование схемы базы данных с использованием веб-интерфейса.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 01.11.2011 |
| Размер файла | 2,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Курсовая работа
"Модели данных, поддерживаемые СУБД. Концепция и разработка распределенных СУБД"
Реферат
Объем работы 45 листов, в том числе 9 рис., 3 табл., 8 наим.лит., 7 приложений. Ключевые слова: распределенная СУБД, распределение данных, интернет-магазин.
В курсовой работе закреплены и конкретизированы теоретические знания в области распределённых баз данных в экономике, развиты навыки по практическому использованию технологии распределённых баз данных для организации бизнеса в секторе сетевой экономики: а) Раскрытие основы концепции и разработки распределенных систем управления базами данных. б) Разработан электронный магазин рынка книг в интерактивной среде Интернет.
В результате проведенной работы сделаны следующие выводы:
1) Распределенная база данных - это совокупность множества взаимосвязанных баз данных, распределенных в компьютерной сети.
2) Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей.
3) В результате анализа предметной области интернет-магазина выявлены сущности: тип товаров, книги, покупатели, заказы, партнер.
4) Чтобы работать с базой данных, нужно выполнить несколько действий: соединиться с сервером баз данных, выбрать базу данных, выполнить SQL-запрос, вывести данные полученные в результате запроса.
5) Разработанный интернет-магазин включает главную страницу, каталог товаров, описание характеристик и цен товаров, возможность заказа выбранных товаров.
6) База данных и web-интерфейс работают независимо друг от друга. Программное обеспечение способно реализовывать основные функции интернет-магазина. Полученную базу данных можно легко обновлять, добавлять данные, производить выборку.
Содержание
- Введение
- 1. Модели данных, поддерживаемые СУБД. Концепция и разработка распределенных СУБД
- 1.1 Основные концепции распределенных СУБД. Распределенные СУБД: достоинства и недостатки
- 1.2 Проблемы, связанные с распределением данных. Поддержка соответствия базы данных вносимым изменениям. Доступ к общим данным
- 1.3 Функции и архитектура распределенной ИС
- 1.4 Разработка распределенных рБД
- 1.5 12 правил Дейта для распределенных СУБД
- Выводы
- 2. Проектирование базы данных в терминах ER-моделирования
- 2.1 Описание предметной области
- 2.2 Построение концептуальной модели базы данных
- 2.3 Разработка логической модели базы данных
- 3. Реализация модели базы данных в интерактивной среде интернет
- 3.1 Построение физической модели данных на языке SQL средствами СУБД MySQL
- 3.2 Реализация проектируемой схемы базы данных с использованием Веб-интерфейса, созданного на языке программирования РНР
- Заключение
- Список использованных источников
- Приложения
- информационный интернет магазин веб интерфейс
Введение
Становление систем управления базами данных совпало по времени со значительными успехами в развитии технологий распределенных вычислений и параллельной обработки. В результате возникли системы управления распределенными базами данных и системы управления параллельными базами данных. Именно эти системы становятся доминирующими инструментами для создания приложений интенсивной обработки данных.
Благодаря интеграции рабочих станций в распределенную среду становится возможным более эффективное распределение функций в ней, когда прикладные программы выполняются на рабочих станциях, называемых серверами приложений, а базы данных обслуживаются выделенными компьютерами, называемыми серверами баз данных. Это послужило источником развития таких распределенных архитектур, где в роли узлов выступают не просто компьютеры общего назначения, а специализированные серверы.
Целью данной работы является:
§ углубление, закрепление и конкретизация теоретических знаний в области распределённых баз данных в экономике;
§ развитие навыков по практическому использованию технологии распределённых баз данных для организации бизнеса в секторе сетевой экономики посредством языка программирования РНР;
§ развитие навыков самостоятельного проектирования распределённых баз данных на языке SQL;
§ приобретение способностей и получение практических навыков по созданию сайтов по определённой тематике, используя технологии распределенных баз данных при управлении предприятием (фирмой) средствами СУБД MySQL.
Для достижения цели работы решаются следующие задачи:
1 Раскрытие основ концепции и разработки распределенных систем управления базами данных.
2 Разработка электронного магазина рынка книг в интерактивной среде Интернет.
1. Модели данных, поддерживаемые СУБД. Концепция и разработка распределенных СУБД
1.1 Основные концепции распределенных СУБД. Распределенные СУБД: достоинства и недостатки
Системы управления базами данных (СУБД) стали сегодня общепризнанным инструментом создания прикладных программных систем. Эти инструментальные средства постоянно совершенствуются и фирмы-разработчики СУБД внимательно следят за успехами своих конкурентов, пытаясь оперативно включить в свои пакеты новые функции, реализованные у конкурентов. Правда внутренняя архитектура СУБД не всегда позволяет сделать это удачно.
Одной из наиболее интересных новых возможностей современных мощных коммерческих СУБД является поддержка распределенных баз данных. Распределенные базы данных реализуются в локальной или глобальной компьютерной сети. При этом части одной логической базы данных располагаются в разных узлах сети, возможно на разнотипных компьютерах с различными операционными системами. Даже данные одной таблицы реляционной СУБД могут физически храниться в разных узлах сети, размещенных, например, в разных городах страны. Причем пользователи любого узла такой распределенной СУБД имеют доступ к данным всех остальных узлов. Такое распределение данных позволяет, например, хранить в узле сети те данные, которые наиболее часто используются в этом узле. Такой подход облегчает и ускоряет работу с этими данными и оставляет возможность работать с остальными данными БД, хотя для доступа к ним требуется потратить некоторое время на передачу данных по сети.
Основной особенностью распределенной базы данных является ее "прозрачность" для пользователей и разработчиков приложений. Т.е. пользователи и разработчики представляют распределенную БД в виде некоторой единой логической локальной БД, не задумываясь о физическом расположении ее компонент. Все приложения создаются так, как будто бы они работают с этой единой логической локальной БД. Отладка приложений также может выполняться на локальной БД.
Перенесение частей этой локальной БД в различные узлы сети может выполняться в более позднее время администратором БД и оно не влечет за собой изменения приложений. Более того, пользователи и разработчики приложений могут даже не знать о том, где теперь физически размещены данные, с которыми они работают. Поиск и пересылку удаленных данных автоматически выполняют программные средства СУБД.
Конечно для того, чтобы реализовать такой простой для конечного пользователя и разработчика механизм представления распределенной БД, необходимо решить множество проблем. Наиболее очевидные из них связаны с обеспечением целостности и непротиворечивости данных распределенной БД, реализацией механизма поддержки "прозрачности" распределенной БД, реализацией единого механизма работы с частями БД, находящимися в СУБД различного типа и расположенными на разнотипных компьютерах с различными операционными системами, обеспечением приемлемого быстродействия прикладной системы и т.д.
Сегодня многие фирмы - разработчики СУБД заявляют о том, что они поддерживают работу с распределенными БД, однако при ближайшем рассмотрении в большинстве случаев эти заявления оказываются несколько преувеличенными. Специалисты в области СУБД считают, что только несколько пакетов СУБД позволяют в некоторой степени реализовать распределенную базу данных.
По определению, распределенная база данных (DDB - distributed database) - это совокупность множества взаимосвязанных баз данных, распределенных в компьютерной сети [6, c.20].
К сожалению на сегодняшний день ни одна СУБД полностью не реализует это определение.
Наиболее близко к его реализации подошли следующие СУБД:
- Informix On-Line фирмы Informix Software;
- Ingres Intelligent Database фирмы Ingres Corp;
- Oracle (version 7) фирмы Oracle Corp;
- Sybase System 10 фирмы Sybase Inc.
Хотя ни одна из этих 4 СУБД полностью не реализует все функции распределенной СУБД, однако каждая из них реализует или в скором времени будет реализовывать поддержку работы с распределенной БД.
Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей [6, c.21]. В этом определении следует уточнить два отличительных условия. Первое заключается в том, что система состоит из (возможно, пустого) множества узлов приема запросов (query site) и непустого множества узлов данных (data site). Узлы данных обладают средствами для хранения данных, а узлы приема запросов - нет; на них лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Второе условие заключается в том, что узлы логически представляют собой независимые компьютеры, на которых установлены собственные операционные системы (может быть, одинаковые на всех узлах, а возможно, и разные) и могут выполняться независимые приложения. Т. е. узлы - это компьютеры, связанные сетью, а не процессоры, составляющие многопроцессорную конфигурацию. Важнейший отличительный признак - слабосвязанный характер среды, где каждый узел имеет собственную операционную систему и функционирует независимо.
База данных физически распределяется по узлам данных при помощи фрагментации и репликации, или тиражирования, данных. Отношения, принадлежащие реляционной базе данных, могут быть фрагментированы на горизонтальные или вертикальные разделы. Горизонтальная фрагментация реализуется при помощи операции селекции, которая направляет каждый кортеж отношения в один из разделов, руководствуясь предикатом фрагментации. Например, для отношения Employee (Сотрудник) возможна фрагментация в соответствии с территориальным распределением рабочих мест сотрудников. При вертикальной фрагментации отношение делится на разделы при помощи операции проекции. Например, один раздел отношения Employee может содержать поля Номер_сотрудника, ФИО_сотрудника, Адрес_сотрудника, а другой - поля Номер_сотрудника, Оклад, Руководитель. За счет фрагментации данные приближаются к месту их наиболее интенсивного использования, что потенциально снижает затраты на пересылки; уменьшаются также размеры отношений, участвующих в пользовательских запросах.
Фрагменты данных могут также тиражироваться с учетом спроса на доступ к ним. Это полезно, если доступ к одним и тем же данным нужен из приложений, выполняющихся на разных узлах. В таком случае, с точки зрения экономии затрат, более эффективно будет поддерживать копии данных на всех узлах, чем непрерывно пересылать данные между узлами.
Распределенные системы баз данных имеют дополнительные преимущества перед традиционными централизованными системами баз данных. К сожалению, эта технология не лишена и некоторых недостатков. Ниже описаны как преимущества, так и недостатки, свойственные распределенным СУБД [4, c.820].
К преимуществам распределенных систем баз данных относятся:
· Отражение структуры организации
· Высокая степень разделяемости и локальной автономности
· Повышение доступности данных
· Повышение надежности
· Повышение производительности
· Экономические выгоды
· Модульность системы
К недостаткам распределенных систем баз данных относятся:
· Повышение сложности
· Увеличение стоимости
· Проблемы защиты
· Усложнение контроля за целостностью данных
· Отсутствие стандартов
· Недостаток опыта
· Усложнение процедуры разработки базы данных
1.2 Проблемы, связанные с распределением данных. Поддержка соответствия базы данных вносимым изменениям. Доступ к общим данным
Одной из важнейших проблем современных распределенных СУБД является проблема распределения данных. В связи с этим, при выборе распределенной СУБД в первую очередь следует обратить внимание на то, какие методы распределения данных реализованы в СУБД.
Один из способов распределенного хранения таблиц - это фрагментация. Таблица может быть расщеплена на части, которые будут помещены в разные узлы. Другой способ распределения данных - это дублирование (репликация). Можно создать дубли всей БД или ее частей и разместить эти дубли в узлах. Оба метода позволяют хранить данные именно в том узле, где они наиболее часто используются. Это сводит к минимуму затраты на передачу данных по сети и уменьшает использование процессоров и прочих ресурсов остальных узлов. При такой архитектуре БД приложения передача данных по сети выполняется достаточно редко.
Ни одна из рассматриваемых СУБД не реализует фрагментацию таблиц полностью. Однако для любой из рассмотренных СУБД программисты могут написать программы, которые будут имитировать фрагментацию. Хорошим средством фрагментации является и использование механизма представлений (views).
После того, как данные распределены по разным узлам сети, важно найти и использовать эти данные. Для того, чтобы найти данные и преобразовать их в нужный формат, используются глобальные словари данных и директории. В словаре хранится информация о данных, их использовании, правах доступа к данным, а также о приложениях. Директории данных используются для того, чтобы определить, где хранятся данные и как их извлечь. Словари и директории могут быть глобальными и локальными.
Методы распределения данных конечно очень важны, однако сердцем современных распределенных СУБД является протокол двухфазной фиксации изменений. Этот протокол управляет выполнением транзакций, изменяющих данные нескольких узлов. Основная идея двухфазной фиксации заключается в следующем: недопустима ситуация при которой транзакция, изменяющая данные в нескольких узлах, выполняется в одних узлах и не выполняется в других узлах. Транзакция должна быть либо успешно выполнена во всех узлах, либо не выполнена ни в одном узле.
Важной характеристикой распределенной БД является то, как она обеспечивает поддержку ссылочной целостности между данными таблицы-мастера и данными связанных с ней таблиц. Для обеспечения ссылочной целостности используются 2 различных метода - триггеры и декларативные ограничения целостности стандарта.
Триггеры обычно используются для того, чтобы выполнить некоторую обработку данных, необходимую для конкретного приложения. Триггер - это небольшой фрагмент программы, написанный на языке программирования СУБД. Этот фрагмент является частью приложения. Примеров триггера может служить триггер обеспечения связи мастер - деталь при выборке данных.
Декларативные ограничения целостности позволяют записать правила обеспечения целостности не в виде фрагмента программы, а в виде набора правил, которые хранятся в словаре данных и автоматически выполняются ядром системы. Декларативные ограничения формулируются во время описания данных и выполняются для всех приложений, работающих с данной БД. Это позволяет программистам не встраивать триггерные программы реализации таких правил в каждое приложение, а описать их лишь 1 раз.
Если множество пользователей одновременно осуществляют доступ (на чтение и запись) к разделяемой базе данных, то для поддержания согласованного состояния данных необходимо обеспечить синхронизацию доступа. Синхронизация достигается путем применения алгоритмов управления одновременным доступом, гарантирующих критерии корректности, такие как сериализуемость. Доступы пользователей к данным инкапсулируются в рамках транзакций, которые на нижнем уровне оформляются как последовательности операций чтения и записи данных. Алгоритмы управления одновременным доступом обеспечивают свойство изолированности выполнения транзакций, которое заключается в том, что результат транзакции не может зависеть (т. е. изолирован) от других параллельно выполняемых транзакций.
Наиболее популярные алгоритмы управления одновременным доступом основаны на механизме блокировок. В такой схеме всякий раз, когда транзакция пытается получить доступ к какой-либо единице памяти (как правило, странице), на эту единицу накладывается блокировка в одном из режимов - разделяемом или исключительном. Блокировки накладываются в соответствии с правилами совместимости блокировок, исключающими конфликты чтение-запись, запись-чтение и запись-запись. Согласно известной теореме, сериализуемость транзакций заведомо гарантируется, если блокировки, относящиеся к одновременно выполняемым транзакциям, удовлетворяют простому правилу: "Ни одна блокировка от имени какой-либо транзакции не должна устанавливаться, пока не будет снята ранее установленная блокировка". Это правило известно под названием двухфазового блокирования, поскольку транзакция проходит при этом сначала фазу "роста", когда она устанавливает блокировки, а затем фазу "сжатия", когда блокировки снимаются. В общем случае снятие блокировок до завершения транзакции проблематично. Поэтому в большинстве алгоритмов управления одновременным доступом применяется более жесткий подход, когда блокировки не снимаются до конца транзакции.
Для распределенных СУБД возникает задача распространения свойства сериализуемости и алгоритмов управления одновременным доступом на распределенную среду. В таких системах операции, относящиеся к одной транзакции, могут выполняться на нескольких узлах, где располагаются необходимые данные. В этом случае наибольшую сложность представляет задача сериализуемости. Сложность ее связана с тем, что на разных узлах упорядочение одного и того же множества транзакций может оказаться различным. Выполнение множества распределенных транзакций сериализуемо тогда и только тогда, когда:
-выполнение этого множества транзакций сериализуемо на каждом узле;
-упорядочение транзакций на всех узлах одинаково.
Алгоритмы управления распределенным одновременным доступом поддерживают это свойство, называемое глобальной сериализуемостью. В алгоритмах, основанных на блокировании, для этого применяется один из трех методов: централизованное блокирование, блокирование первичной копии и распределенное блокирование.
При централизованном блокировании для всей распределенной базы данных поддерживается единая таблица блокировок. Эта таблица, располагаемая на одном из узлов, находится под управлением единого менеджера блокировок. Менеджер блокировок отвечает за установку и снятие блокировок от имени всех транзакций. Поскольку управление блокировками сосредоточено на одном узле, то оно аналогично централизованному управлению одновременным доступом, и глобальная сериализуемость обеспечивается достаточно легко. Соответствующие алгоритмы просты в реализации, но с ними связаны две проблемы. Во-первых, центральный узел может стать узким местом как из-за большого объема обработки данных, так и из-за генерируемого вокруг него интенсивного сетевого трафика. Во-вторых, надежность такой системы ограничена, поскольку отказ или недоступность центрального узла приводит к выходу из строя всей системы.
Блокирование первичной копии - это алгоритм управления одновременным доступом, применяемый для баз данных с репликациями, где копии одних и тех же данных могут храниться на множестве узлов. Одна из таких копий выделяется как первичная, и для доступа к любому элементу данных необходимо установить блокировку на его первичную копию. Множество первичных копий элементов данных известно всем узлам распределенной системы, и запросы транзакций на блокирование направляются узлам, где хранятся первичные копии. Если в распределенной базе данных репликации не используются, то данный алгоритм сводится к алгоритму распределенного блокирования.
Алгоритм распределенного (или децентрализованного) блокирования предполагает распределение обязанностей по управлению блокировками между всеми узлами системы. Для выполнения транзакции необходимо участие и взаимная координация менеджеров блокировок на нескольких узлах. Блокировки устанавливаются на всех узлах, данные которых участвуют в транзакции. Алгоритмам распределенного блокирования не свойственны недостатки механизма централизованного блокирования, связанные с перегруженностью центрального узла. Однако алгоритмы этого типа сложнее, а коммуникационные затраты, необходимые для установки всех требуемых блокировок, выше.
Общий побочный эффект всех алгоритмов управления одновременным доступом посредством блокирования - возможность тупиковых ситуаций. Задача обнаружения и преодоления тупиков особенно сложна в распределенных системах. Тем не менее, благодаря относительной простоте и эффективности алгоритмов блокирования, они имеют значительно большую популярность, чем альтернативные алгоритмы, основанные на временных метках, а также алгоритмы оптимистичного управления одновременным доступом. Алгоритмы, основанные на временных метках, выполняют конфликтующие операции транзакций в соответствии с временными метками, присвоенными транзакциям при их регистрации. Алгоритмы оптимистичного управления исходят из предположения о том, что конфликты между транзакциями редки, и доводят транзакцию до конца, а затем производят проверку корректности. Если выясняется, что фиксация данной транзакции повлечет нарушение сериализуемости, то транзакция откатывается и запускается снова.
1.3 Функции и архитектура распределенной ИС
В большинстве случаев распределенная СУБД состоит из ядра СУБД и набора дополнительных продуктов, покупаемых отдельно, которые обеспечивают работу с распределенной БД. Некоторые фирмы-разработчики СУБД встраивают средства работы с распределенной БД в ядро СУБД. Кроме того, различные фирмы вкладывают разные понятия в термин "распределенная СУБД" и по разному определяют набор необходимых для такой СУБД функций. Поэтому потенциальным покупателям распределенных СУБД очень непросто сравнивать эти СУБД между собой и делать правильный выбор. Однако существует некоторый набор функций, которые должны быть присущи каждой распределенной СУБД. Наиболее распространенным описанием этих функций является следующее:
-Распределенная СУБД обеспечивает пользователям доступ к информации независимо от того, какое оборудование и какое прикладное программное обеспечение используется в узлах сети. Пользователи при этом не обязаны знать, где физически размещаются данные и как надо выполнять физический доступ к ним. Распределенная СУБД позволяет выполнять горизонтальное и вертикальное "расщепление" таблиц и помещать данные одной таблицы в различных узлах сети. Запросы к данным распределенной БД формулируются так, как будто база данных локальна. При обработке транзакций и выполнении операций копирования/восстановления распределенной БД обеспечивается целостность всей БД.
-Протоколы управления БД, например протокол двухфазной фиксации изменений, реализуют механизмы блокировки, обеспечивающие непротиворечивость данных. Средства глобальной оптимизации запросов автоматически выбирают наилучший способ выполнения в локальной или глобальной сети сложных транзакций, а специальные мониторы позволяют получать информацию о параметрах выполняющихся в разных узлах процессов и на основе этой информации выполнять настройку системы с целью обеспечения максимальной производительности работы.
Президент фирмы Alternative Technologies Макговерн сформулировал 13 основных функций, которые должна поддерживать распределенная СУБД. Рассмотрим их подробнее [7, c.116].
1. Распределенный словарь (дирректория) данных. в словаре содержится информация о типе данных, месте их размещения и о способе доступа к данным.
2. Прозрачный протокол двухфазной фиксации изменений. Этот протокол обеспечивает непротиворечивость данных. При выполнении транзакции, изменяющей данные в нескольких узлах, протокол двухфазной фиксации обеспечивает успешное выполнение всей транзакции только в том случае, если успешно выполнилась обработка в каждом узле. Если же в одном из узлов обработка не выполнена успешно, то аннулируются результаты работы всей транзакции.
3. Горизонтальная и вертикальная фрагментация. Эта функция позволяет "расщеплять" таблицу БД по строкам (горизонтально) и по столбцам (вертикально) и размещать части данных таблицы в разных узлах сети.
4.Независимость дублирования данных. Это свойство СУБД позволяет создавать в узлах сети дубли данных без снижения производительности приложения и без нарушения непротиворечивости данных.
5. Распределенные представления (views). Представления могут формироваться при выполнении операции соединения (join) таблиц, размещающихся в разных узлах.
6. Оптимизация распределенных запросов. Оптимизация алгоритмов выполнения сложных операций, например соединения таблиц, выполняется с учетом размещения данных в глобальной сети. При этом учитывается пропускная способность сети, ее загрузка и объем передаваемой информации, вычислительная мощность узлов. На основе этой информации делается вывод о том, где лучше всего производить операцию соединения таблиц (как наиболее трудоемкую операцию).
7. Распределенные ограничения целостности. Эта функция обеспечивает ссылочную целостность данных. В узлах могут находиться таблицы, зависящие от некоторой таблицы-мастера. При модификации данных таблицы-мастера автоматически модифицируются зависимые таблицы.
8. Локальная автономия. Администратор БД конкретного узла полностью контролирует данные локальной БД данного узла. Он может работать независимо от администраторов других узлов.
9. Непрерывная обработка (continual operation). Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т.е. в каждом узле обработка выполняется независимо и целиком.
10. Независимость размещения. Изменение места хранения данных не ведет к изменению работающих с этими данными приложений.
11. Обработка распределенных транзакций. Обеспечение ограничений целостности поддерживается и при выполнении транзакции, изменяющей несколько узлов.
12. Глобальная обработка взаимоблокировок и проблем, возникающих при одновременном доступе к данным. Блокировка данных может выполняться во всех узлах БД. Необходимо выявлять и разрешать ситуации, когда два узла взаимно блокируют друг друга.
13. Независимость от типа компьютеров, операционных систем, сетевых протоколов, типов СУБД. Эта независимость осуществляется путем использования как встроенных в СУБД средств, так и шлюзов (gateways).
Существует множество альтернатив распределенной обработки. Наиболее популярна в настоящее время архитектура клиент-сервер, когда множество машин-клиентов осуществляют доступ к одному серверу баз данных. В таких системах, которые можно определить как системы типа много-клиентов/один-сервер, проблемы управления базой данных решаются относительно просто, поскольку вся она хранится на одном сервере. Задачи, с которыми приходится здесь сталкиваться, - это управление буферами клиентов, кэширование данных и, возможно, блокировки. Управление данными реализуется централизованно на одном сервере.
Более распределенной и более гибкой является архитектура типа много-клиентов/много-серверов, когда база данных размещена на множестве серверов, которым, для того чтобы вычислить результат пользовательского запроса или выполнить транзакцию, необходимо взаимодействовать друг с другом. Каждая клиентская машина имеет свой "домашний" сервер; ему она направляет пользовательские запросы. Взаимодействие серверов друг с другом прозрачно для пользователей. В большинстве существующих СУБД реализован один из этих двух типов архитектуры клиент-сервер.
В истинно распределенной СУБД клиентские и серверные машины не различаются. В идеале каждый узел может выступать и как клиент, и как сервер. Такие архитектуры, тип которых определяют как равный-к-равному, требуют сложных протоколов управления данными, распределенными по множеству узлов. Предложение продуктов такого вида задерживается из-за сложности необходимого для их реализации программного обеспечения.
1.4 Разработка распределенных рБД
При разработке распределенных баз данных кроме централизованных реляционных баз данных необходимо рассматривать дополнительные факторы. В частности, рассматриваются следующие аспекты проектирования распределенных систем [4, c.835].
1) Фрагментация. Любое отношение может быть разделено на некоторое количество частей, называемых фрагментами, которые затем распределяются по различным узлам. Существуют два основных типа фрагментов: горизонтальные и вертикальные. Горизонтальные фрагменты представляют собой подмножества строк, а вертикальные -- подмножества атрибутов.
2) Размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы их размещения.
3) Репликация. Распределенная СУБД может поддерживать актуальную копию некоторого фрагмента на нескольких различных узлах.
Определение и размещение фрагментов должно проводиться с учетом особенностей использования базы данных. В частности, это подразумевает выполнение анализа транзакций. Как правило, провести анализ всех транзакций не представляется возможным, поэтому следует сосредоточить усилия на самых важных из них.
Проектирование должно выполняться на основе как количественных, так и качественных показателей. Количественная информация используется в качестве основы для распределения, тогда как качественная служит базой при создании схемы фрагментации. Количественная информация включает такие показатели:
· частота выполнения транзакции;
· узел, на котором выполняется транзакция;
· требования к производительности транзакций.
Качественная информация может включать сведения о выполняемых транзакциях:
· используемые отношения, атрибуты и строки;
· тип доступа (чтение или запись);
· предикаты операций чтения.
Определение и размещение фрагментов по узлам выполняется для достижения следующих стратегических целей.
· Локализация ссылок.
· Повышение надежности и доступности.
· Приемлемый уровень производительности.
· Минимизация расходов на передачу данных.
1.5 12 правил Дейта для распределенных СУБД
В 1987 г. К. Дейт опубликовал свои правила для распределенных баз данных. Ниже приведены эти 12 правил [5, c.414].
1. Локальная автономность. Локальные данные должны находиться под локальным владением и управлением, включая функции безопасности, целостности, представления данных в памяти. Исключением может быть ситуация, когда ограничения целостности охватывают данные нескольких узлов или когда управление распределенной транзакцией осуществляется некоторым внешним узлом.
2. Никакой конкретный сервис не должен возлагаться на какой-либо специально выделенный центральный узел. Соблюдение этого правила, т.е. принципа децентрализованности функций РаСУБД, позволяет избежать узких мест.
3. Непрерывность функционирования. Система не должна останавливаться в случае необходимости добавления нового узла или удаления в распределенной среде некоторых данных, изменения определения метаданных и даже (что довольно сложно) осуществления перехода к новой версии СУБД на отдельном узле.
4. Независимость от местоположения. Пользователи и приложения не обязаны знать о том, где физически располагаются данные.
5. Независимость от фрагментации. Фрагменты (называемые также разделами) данных должны поддерживаться и обрабатываться средствами РаСУБД таким образом, чтобы пользователи или приложения могли бы вообще ничего не знать об этом. Более того, РаСУБД должна уметь обходить при обработке запросов фрагменты, не имеющие к ним отношения (например, РаСУБД должна быть достаточно интеллектуальной, для того чтобы определять, можно ли исключить при обработке запроса тот или иной фрагмент в силу того, что запрос не содержит ссылок на хранящиеся в этом фрагменте столбцы).
6. Независимость от тиражирования. Те же принципы независимости и прозрачности относятся и к механизму тиражирования, который обсуждается ниже.
7. Распределенная обработка запросов. Обработка запросов должна производиться распределенным образом. В следующем разделе мы рассмотрим некоторые архитектурные принципы реализации РаСУБД и различные модели, в рамках которых возможна распределенная обработка запросов.
8. Управление распределенными транзакциями. На распределенные базы данных необходимо распространить механизмы управления транзакциями и управления одновременным доступом. Эта проблема включает выявление и разрешение тупиковых ситуаций, прерывания по истечении временных интервалов, фиксацию и откат распределенных транзакций, а также ряд других вопросов.
9. Независимость от оборудования. Одно и то же программное обеспечение РаСУБД должно выполняться на различных аппаратных платформах и функционировать в системе в качестве равноправного партнера. Как уже обсуждалось выше, на практике достичь этого исключительно сложно, поскольку многие поставщики поддерживают множество платформ. Это ограничение преодолевается с помощью модели многопродуктовых сред.
10. Независимость от операционных систем. Эта проблема тесно связана с предыдущей, и она также решается аналогичным образом.
11. Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI, модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РаБД, но и для информационных систем вообще.
12. Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РаСУБД.
Очевидно, что, хотя крайне желательно было бы иметь системы, удовлетворяющие всем 12 правилам, нереально ожидать реализации этих требований в рамках хотя бы одного продукта даже в ближайшие годы. И действительно, за время, прошедшее с момента опубликования правил Дейта, эта цель так и не была достигнута.
Выводы
Распределенная база данных - это совокупность множества взаимосвязанных баз данных, распределенных в компьютерной сети.
Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей.
При разработке распределенных баз данных кроме централизованных реляционных баз данных необходимо рассматривать дополнительные факторы. В частности, рассматриваются следующие аспекты проектирования распределенных систем: фрагментация, размещение, репликация.
Существует множество альтернатив распределенной обработки. Наиболее популярна в настоящее время архитектура клиент-сервер.
2. Проектирование базы данных в терминах ER-моделирования
2.1 Описание предметной области
С целью более эффективного продвижения продукции на рынке средствами HTML разрабатывается сайт-каталог книжной продукции.
Для организации информации об имеющихся товарах создается база данных.
В результате анализа предметной области книжных интернет-магазинов мы выявили следующие сущности:
Тип товаров (type).
Книги (book).
Покупатели (klient).
Заказ (zakaz).
Партнер (partner).
Определим типы связей существующих между выделенными нами сущностями. Для этого снова анализируем требования к БД. Тип связи представляет собой название связи, ее координальность в этой связи. Результат анализа представлен в таблице 2.1.
Таблица 2.1 Типы связей между сущностями
|
Тип сущности |
Тип связи |
Тип сущности |
Координальность |
|
|
type |
принадлежит (belong) |
book |
||
|
klient |
оформляет (bill) |
schet |
||
|
book |
принадлежит(belong) |
zakaz |
||
|
partner |
продает(sell) |
book |
2.2 Построение концептуальной модели базы данных
На следующем этапе проектирования базы данных мы построим ER-диаграмму отражающую основные виды сущностей и связи между ними (рис. 2.1).
Рис. 2.1 ER-диаграмма концептуальной модели.
Выявленные атрибуты сущностей приведены в таблице 2.
Таблица 2.2 Атрибуты сущностей и связей
|
Тип сущности(связи) |
Атрибут |
Домен |
Обязатель-ность |
|
|
BOOK |
id |
Целое |
Да |
|
|
name |
Символьный |
|||
|
author |
Символьный |
|||
|
year |
Целое |
|||
|
izdat |
Символьный |
Да |
||
|
info |
Символьный |
|||
|
type |
Целое |
|||
|
cost |
Целое |
|||
|
PARTNER |
id |
Целое |
Да |
|
|
fio |
Символьный |
Да |
||
|
phone |
Символьный |
|||
|
address |
Символьный |
|||
|
sell |
Целое |
|||
|
book_id |
Целое |
|||
|
ZAKAZ |
id |
Целое |
Да |
|
|
klient |
Целое |
Да |
||
|
book |
Целое |
|||
|
kolvo |
Целое |
|||
|
POKUPATEL |
id |
Целое |
Да |
|
|
name |
Символьный |
Да |
||
|
phone |
Символьный |
Да |
||
|
address |
Символьный |
Да |
||
|
TYPE |
id |
Целое |
Да |
|
|
type |
Символьный |
Да |
Определим атрибуты, являющиеся потенциальными и первичными ключами.
Для этого из таблицы 2.2 выберем возможные потенциальные ключи. Затем из них выберем первичные ключи.
Составим таблицу первичных и альтернативных ключей (табл. 2.3).
Таблица 2.3 Первичные и альтернативные ключи
|
Сущность |
Первичный ключ |
Альтернативный ключ |
|
|
BOOK |
id |
nazvanie |
|
|
PARTNER |
id |
fio, phone |
|
|
ZAKAZ |
id |
||
|
POKUPATEL |
id |
name, phone |
|
|
TYPE |
id |
type |
2.3 Разработка логической модели базы данных
При построении логической модели можно использовать язык ER-диаграмм. В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью.
Логическая модель базы данных приведена на рисунке 2.2.
Рис. 2.2 ER-диаграмма логической модели базы данных книжного магазина
В результате анализа предметной области интернет-магазина были выявлены следующие сущности: Тип товаров (type), Книги (book), Покупатели (klient), Заказ (zakaz), Партнер (partner).
Сущность type связана отношением "принадлежит" с сущностью condition, сущность klient связана отношением "заказывает" с сущностью zakaz, сущность condition связана отношением "заказывает" с сущностью zakaz, сущность company связана отношением "продает" с сущностью condition.
3. Реализация модели базы данных в интерактивной среде интернет
3.1 Построение физической модели данных на языке SQL средствами СУБД MySQL
Теперь наша задача - построить таблицы основываясь на логической модели базы данных. Правила перевода из логической модели данных в физическую следующие:
Объекты становятся таблицами в физической базе данных
Атрибуты становятся колонками (полями) в физической базе данных. Для каждого атрибута выбирается свой тип данных.
Уникальные идентификаторы становятся колонками, не допускающими значение NULL. В физической базе данных они называются первичными ключами (primary key).
Схема таблиц базы данных представлена на рис. 3.1.
Рис. 3.1 Схема таблиц для базы данных книжного магазина
Теперь необходимо перевести все эти таблицы в SQL. В общем случае модели данных разрабатываются таким образом чтобы не зависеть от конкретной базы данных. Поэтому разработанную физическую модель данных можно применить к любой СУБД. В нашем случае это будет MySQL. MySQL - компактный многопоточный сервер баз данных. MySQL характеризуется большой скоростью, устойчивостью и легкостью в использовании.
В базе данных MySql таблицы создаются с помощью sql-запроса (см. приложение 1).
3.2 Реализация проектируемой схемы базы данных с использованием Веб-интерфейса, созданного на языке программирования РНР
Сайт-каталог включает:
- Главную страницу
- Каталог товаров
- Описание характеристик и цен товаров
- Возможность заказа выбранных товаров
В сайт планируется включить:
– главную страницу;
– каталог товаров (каталог разбивается на разделы и подразделы с целью систематизации данных и облегчения поиска необходимого товара);
– форму заказа / обратной связи (Для оперативной связи с администрацией сайта).
Общие моменты оформления страниц.
На каждой странице вверху по центру располагается логотип фирмы. Логотип состоит из двух рисунков, которые были разработаны в Adobe Photoshop 7.0 и сохранены под именами - logo.gif и logo1.gif.
Рис. 3.2 Логотип фирмы
Фоновым элементом информационных полей таблиц сайта является зеленый цвет (код цвета - #669999). Это дизайнерское соображение исходит из наиболее цветовой гармонии логотипа с фоном таблиц, как основного элемента сайта, основным текстом - Verdana цвета черный.
Все страницы справочника содержат один и тот же функциональный макет. Первая таблица состоит из двух строк и представляет собой заголовок, верхнюю часть и пустую строку, включенную из дизайнерских соображений, вторая содержи меню сайта и располагается по левую сторону страницы и третья - сам контент, т.е. содержание сайта. Первая и вторая таблицы остаются постоянными по оформлению и содержанию во всем каталоге. Вторая таблица изменяется структурно и содержательно в зависимости от имеющейся информации.
Макет таблиц сайта представлен на рисунке 3.3.
Рис. 3.3 Макет таблиц сайта
Меню представляет собой форматированный текст посредством СSS. Каждый пункт меню находится в отдельной ячейке своей таблицы. Файл стилей - styles.css. Находится в корне каталога и содержит в себе всю информацию о представлении документа в определенном стиле. Пункты меню отформатированы на шрифт Verdana высотой в 12 пикселей. Цвет - синий.
A.menu {
font-family : Verdana, Geneva, Arial, Helvetica, sans-serif;
font-size : 12px;
text-decoration : none;
color : Navy;
font-weight : bold;
}
При наведении курсора мыши на пункт меню, он подсвечивается белым цветом
A.menu:hover, A.menu1:hover {
font-family : Verdana, Geneva, Arial, Helvetica, sans-serif;
font-size : 12px;
text-decoration : none;
color : #E0FFFF;
font-weight : bold;
}
Главная страница содержит краткую информацию об услугах, предоставляемых фирмой. Рекламная информация представляет собой форматированный тегами HTML текст. Переход на другую строку осуществляется при помощи тега <br>. Главная страница имеет имя: index.php
Рассмотрим сценарий отображающий главную страницу.
Одной из главных частей работы является работа с базой данных.
Чтобы работать с базой данных нужно выполнить несколько действий:
Соединиться с сервером баз данных
@mysql_connect($dblocation,$dbuser,$dbpasswd);
где $dblocation - Имя сервера
$dbuser - Имя пользователя
$dbpasswd - Пароль
Выбрать базу данных
@mysql_select_db($dbname, $dbcnx);
где $dbname - Имя БД
$dbcnx - соединение с БД
Выполнить SQL-запрос
mysql_query("$zapros");
где $ zapros - Запрос
Вывести данные полученные в результате запроса
$item = mysql_fetch_array($ath);
где $ath - Запрос
$item - строка таблицы запроса
На главной странице производим выборку видов товаров с помощью следующего sql-запроса:
Select * from type
Вид главной страницы в показан в приложении 2.
В URL передается идентификатор вида запроса, в соответствии с которым будет сделана выборка. Т.е. выполнится следующий sql-запрос:
Select * from Book where type='$type',
где $type - переменная переданная в URL.
Вид каталога в броузере показан в приложении 3.
Далее нужно чтобы пользователь, нажав на ссылку, мог оформить заказ, заполнив поля формы. Внешний вид сценария реализующего форму заказа показаны в приложениях 5, 6.
После нажатия на кнопку заказать данные записываются в базу данных с помощью sql-оператора INSERT. Данный скрипт описан в приложении 7.
Выводы
В ходе разработки электронного магазина был написан web-интерфейс на языке PHP с применением MySQL.
База данных и web-интерфейс работают независимо друг от друга. Программное обеспечение способно реализовывать основные функции интернет-магазина.
Полученную базу данных можно легко обновлять, добавлять данные, производить выборку.
Заключение
Распределенная база данных - это совокупность множества взаимосвязанных баз данных, распределенных в компьютерной сети.
Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей.
Преимущества распределенной СУБД заключаются в том, что она позволяет отразить организационную структуру и повышает возможности совместного использования удаленных данных, а также повышает надежность, доступность и производительность системы, позволяет получить экономию средств и обеспечивает модульное наращивание мощности всей системы. Основными ее недостатками являются более высокая стоимость, сложность, отсутствие стандартов и нехватка опыта разработки и эксплуатации.
При разработке распределенных баз данных кроме централизованных реляционных баз данных необходимо рассматривать дополнительные факторы. В частности, рассматриваются следующие аспекты проектирования распределенных систем: фрагментация, размещение, репликация.
Существует множество альтернатив распределенной обработки. Наиболее популярна в настоящее время архитектура клиент-сервер. Более распределенной и более гибкой является архитектура типа много-клиентов/много-серверов.
В истинно распределенной СУБД клиентские и серверные машины не различаются.
В результате анализа предметной области интернет-магазина выявлены сущности: тип товаров, книги, покупатели, заказы, партнер.
Чтобы работать с базой данных, нужно выполнить несколько действий: соединиться с сервером баз данных, выбрать базу данных, выполнить SQL-запрос, вывести данные полученные в результате запроса.
Разработанный интернет-магазин включает главную страницу, каталог товаров, описание характеристик и цен товаров, возможность заказа выбранных товаров.
База данных и web-интерфейс работают независимо друг от друга. Программное обеспечение способно реализовывать основные функции интернет-магазина. Полученную базу данных можно легко обновлять, добавлять данные, производить выборку.
Список использованных источников
1. Будилов В.А. Практические занятия по PHP4. -СПб.: Наука и техника, 2001. -352 с.: ил.
2. Вишняков В.А. Информационный менеджмент: в 8 ч.Ч 6: Распределенные БД в экономике и управлении.- Мн.: Изд-во МИУ, 2005.-250с
3. Грофф Дж.Р. SQL - Полное руководство. Киев: BHV, 2001. - 798 с.
4. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: пер. с англ.:Уч. Пособ. -М.: Издательский дом "Вильямс", 2000. -1120 с.: ил.
5. Малыхина М.П. Базы данных: основы, проектирование, использование. - Спб.: БХВ-Петербург, 2004. -512 с.: ил.
6. М. Тамер Оззу, Патрик Валдуриз. Распределенные и параллельные системы баз данных // Системы Управления Базами Данных №4/96
7. Смородинский А. В., Ривкин М. Н. Системы управления базами данных и оболочки экспертных систем для персональных компьютеров. - Тверь, 2001.
8. Хансен Г., Хансен Д. Базы данных: разработка и управление. Пер. с англ. -М.: ЗАО "Изд-во БИНОМ", 1999. -704 с.: ил.
Приложение 1
Создание таблиц в MySQL
CREATE TABLE book(
id int(6) NOT NULL auto_increment,
img text,
name text,
info text,
type int(3),
author text,
izdat text,
year int(4),
cost int(8),
partner_id int(11),
PRIMARY KEY (id));
CREATE TABLE type(
id int(3) NOT NULL auto_increment,
type text,
PRIMARY KEY (id));
CREATE TABLE partner(
id int NOT NULL auto_increment,
fio text,
phone text,
address text,
sell int(8),
company text,
PRIMARY KEY (id));
CREATE TABLE zakaz(
id int NOT NULL auto_increment,
cd int(6),
kolvo int(3),
klient int,
PRIMARY KEY (id));
CREATE TABLE klient(
id int NOT NULL auto_increment,
name text,
tel text,
adress text,
info text, PRIMARY KEY (id));
Приложение 2
Скрипты файла INDEX.PHP
Рис. П.2.1 Внешний вид файла INDEX.PHP
<?php include ("mysql.php");?>
<html>
<head>
<title>Главная</title>
<link rel="STYLESHEET" type="text/css" href="style.css">
</head>
<body background="pics/bg.jpg" topmargin="0">
<table class="main" cellspacing="4" cellpadding="0" border="0" width="812" align="center" height="100%">
<tr>
<td colspan="2" height="80" width="882" bgcolor="#669999"> <img border="0" src="pics/logo.gif" width="57" height="76"><img border="0" src="pics/logo1.gif" width="73" height="38"></td>
</tr>
<tr>
<td width="880" valign="top" bgcolor="#000000" colspan="2" bordercolor="#000000">
</td>
</tr>
<tr>
<td width="127" valign="top" bgcolor="#669999">
<table cellspacing="2" cellpadding="0" border="0" class="menu" width="120">
<tr>
<td align="center" height="25"><a class="menu" href="index.php">Главная</a></td>
</tr>
<tr>
<td align="center" height="25"><a class="menu" href="order.php">Заказать</a></td>
</tr>
<tr>
<td align="center" height="25"><strong>Каталог</strong></td>
</tr>
<tr>
<td align="center">
<?php
db_catalog();
?>
</td>
</tr>
</table>
</td>
<td valign="top" align="" width="753" height="100%" bgcolor="#669999">
<p align="center"><font><br>
<font face="Times New Roman" size="5"><b><u>ДОБРО
ПОЖАЛОВАТЬ</u></b></font>
</font></p>
<p style="TEXT-ALIGN: justify"><span style="COLOR: #333399"><font face="Times New Roman" size="3" color="#003399">В
нашем Интернет-магазине представлен ряд
учебных пособий по экономике,
программированию и естественным наукам. </font></span></p>
<p style="TEXT-ALIGN: justify"><span style="COLOR: #333399"><font face="Times New Roman" size="3" color="#003399">
Вас приятно удивят цены и скорость
доставки. </font></span></p>
<p style="TEXT-ALIGN: justify"><span style="COLOR: #333399"><font face="Times New Roman" size="3" color="#003399"> Весь товар постоянно в наличии. </font></span></p>
<p style="TEXT-ALIGN: justify"><span style="COLOR: #333399"><font face="Times New Roman" size="3" color="#003399">
Постоянные клиенты получают скидки. </font></span></p>
<p align="center"><font size="3" color="#3366CC" face="Times New Roman"><span style="COLOR: #003366"><b>Заказывайте
прямо сейчас!</b></span></font></p>
<font face="Times New Roman" size="3" color="#003399"><span class="headline">Дополнительная
Подобные документы
Теоретические аспекты СУБД. Основные понятия. Функциональные возможности СУБД. Архитектура систем управления. Разработка базы данных. Крупные массивы данных размещают, как правило, отдельно от исполняемого программы, и организуют в виде базы данных.
курсовая работа [30,5 K], добавлен 23.02.2006Построение инфологической (концептуальной) модели предметной области. Проектирование логической и физической структуры базы данных. Реализация проекта в среде конкретной СУБД. Организация корректировки и ввода данных в БД. Разработка интерфейса.
курсовая работа [1,4 M], добавлен 14.01.2018Система управления базами данных (СУБД) как программная система для создания общей базы данных. Создание СУБД для управления поставкой и реализацией ювелирных изделий. Типы данных, физическая и логическая модели. Разработка интерфейса пользователя.
курсовая работа [467,8 K], добавлен 14.12.2012Разработка информационно-аналитической системы агентства недвижимости. Обоснование выбора архитектуры базы данных и СУБД. Моделирование потоков данных (DFD диаграмм). Проектирование инфологической модели данных с использованием модели "сущность-связь".
дипломная работа [5,4 M], добавлен 06.06.2013Выбор, обоснование и особенности работы СУБД. Характеристика языков программирования. Разработка структурной и функциональной модели информационной системы аптеки. Проектирование программной среды АИС и ее интерфейса. Построение модели базы данных.
курсовая работа [442,3 K], добавлен 21.04.2012Системы управления базами данных: сущность и характеристика. Типы данных и свойства полей СУБД Access. Объекты базы данных: таблицы, схемы данных, формы, запросы, отчеты. Разработка и проектирование базы данных "Продажи книг" в среде Microsoft Access.
курсовая работа [1,8 M], добавлен 04.02.2013Разработка программного приложения WindowsForms для работы с базой данных на языке высокого уровня C# в автономном режиме с использованием ADO.NET. Проектирование реляционной модели базы данных, интерфейса приложения, основных функций и возможностей.
курсовая работа [4,3 M], добавлен 30.06.2015Проектирование даталогической модели в виде логической структуры реляционной базы данных в СУБД Microsoft SQL Server на основе созданной инфологической модели базы данных интернет-магазина музыки. Выделение сущностей и связей, анализ предметной области.
курсовая работа [724,6 K], добавлен 15.06.2013Учет книжного фонда библиотеки. Разработка концептуальной модели данных. Составление спецификации атрибутов и связей, генерация в системе PowerDesigner физической модели по концептуальной модели. Создание скрипта создания базы данных для СУБД FireBird.
контрольная работа [784,2 K], добавлен 10.04.2014Краткая история развития СУБД ORACLE, основные понятия и определения, архитектура. Принципы работы с СУБД ORACLE. Разработка баз данных, средства и технологии их реализации; возможности процедурного языка PL/SQL. Приемы администрирования СУБД ORACLE.
презентация [609,2 K], добавлен 14.02.2014
