Загрузка...
Учебная работа. Курсовая работа: Разработка СУБД
Введение…………………………………………………….2
Глава 1.
Теоретические нюансы СУБД
1. Главные понятия……………………………………….3
2. Многофункциональные способности СУБД…………………7
3. Архитектура систем управления………………………..9
4. Типы СУБД………………………………………………13
Глава 2
. Разработка базы данных
………………16
Заключение………………………………………………….21
Перечень литературы…………………………………………22
Введение.
Развитие средств вычислительной техники обеспечило для сотворения и широкого использования систем обработки данных различного предназначения. Разрабатываются информационные системы для обслуживания разных систем деятельности, систем управления хозяйственными и техническими объектами, модельные комплексы для научных исследовательских работ, системы автоматизации проектирования и производства, различные тренажеры и обучающие системы. Одной из принципиальных предпосылок сотворения таковых систем стала возможность оснащения их «памятью» для скопления, хранения и классификация огромных размеров данных. иной значимой предпосылкой необходимо признать разработку подходов, также создание программных и технических средств конструирования систем, созданных для коллективного использования. В данной связи потребовалось создать особые способы и механизмы управления такового рода вместе применяемыми ресурсами данных, которые стали называться базами данных. Исследования и разработки, связанные с проектированием, созданием и эксплуатации баз данных, также нужных для этих целейязыковых и программных инструментальных средств привели к возникновению самостоятельной ветки информатики, получившей заглавие системы управления данными.
Такие программные комплексы делают достаточно непростой набор функций, связанный с централизованными управлениями, данными в базе данных интерфейсах всей совокупы ее юзеров. По существу, система управления базами данных служит посредником меж юзерами и базой данных.
В истинное время разработаны и употребляются на индивидуальных компах около 20 систем управления базами данных. Они представляют юзеру комфортные средства интерактивного взаимодействия с БД и имеют развитый язык программирования
Данная работа представлена некие теоретические нюансы теории Б, главные понятия, многофункциональные способности систем управления БД, также описана БД по рынку бытовой химии городка Улан-Удэ.
I
. Теоретические нюансы СУБД.
1. Главные понятия БД.
Всякая прикладная программка является отображением какой – то части настоящего мира и потому содержит его формализованное описание в виде данных.
Большие массивы данных располагают, как правило, раздельно от исполняемого программки, и организуют в виде Базы данных.
Начиная с 60-х годов для работы с данными, стали употреблять особенные программные комплексы, именуемые системами управления базами данных (СУБД).
системы управления базами данных отвечают за:
— физическое размещение данных и их описаний;
— поиск данных;
— поддержание баз данных в животрепещущем состоянии;
— защиту данных от неправильных обновлений и несанкционированного доступа;
сервис одновременных запросов к данным от нескольких юзеров (прикладных программ).
Модели данных
.
Хранимые в базе данных имеют определенную логическую структуру, другими словами, представлены некой моделью, поддерживаемой СУБД. К числу важных относятся последующие модели данных:
— иерархическая;
— сетевая;
— реляционная;
— обЪектно – направленная;
В иерархической модели данные представляются в виде древовидной (иерархической) структуры. Она комфортна для работы с иерархически упорядоченной информацией и громоздка для инфы со сложными логическими связями.
Сетевая модель значит признаков, которыми должны владеть все определенные СУБД и управляемые ими БД, если они основываются на данной модели.
Объектно-ориентировочная модель данных – это когда в базе хранятся не только лишь данные, да и способы их обработки в виде программного кода. Это перспективное направление, пока также не получившее активного распространения из-за трудности сотворения и внедрения схожих СУБД.
база данных
— это совокупа записей различного типа, содержащая перекрестные ссылки.
файл — это совокупа записей 1-го типа, в каком перекрестные ссылки отсутствуют.
Наиболее того, в определении нет упоминания о компьютерной архитектуре. Дело в том, что, хотя почти всегда БД вправду представляет собой один либо (почаще) несколько файлов, физическая их организация значительно различается от логической. Таблицы могут храниться как в отдельных файлах, так и все совместно. И, напротив, для хранения одной таблицы время от времени употребляются несколько файлов. Для поддержки перекрестных ссылок и резвого поиска обычно выделяются доп особые файлы.
Потому при работе с базами данных обычно используются понятия наиболее высочайшего логического уровня: запись и таблица, без углубления в подробности их физической структуры.
Таковым образом, сама по для себя база данных — это лишь набор таблиц с перекрестными ссылками. Чтоб всепригодным методом извлекать из нее группы записей, обрабатывать их, изменять и удалять, требуются особые программки, именуются СУБД.
По к примеру, СУБД ORACLE и INFORMIX. Многопользовательские СУБД
содержат в себе БД и клиентскую часть, работают в неоднородной вычислительной среде допускаются различные типы ЭВМ и разные операционные системы. Потому на базе СУБДМ можно сделать информационную систему, функционирующую по технологии клиент-сервер. Универсальность многопользовательских СУБД отражается соответственно на высочайшей стоимости и компьютерных ресурсах, требуемых для поддержки
СУБДП представляет собой совокупа языковых и программных средств, созданных для сотворения, ведения и использования БД.
Индивидуальные СУБД
обеспечивают возможность сотворения индивидуальных БД и дешевых приложений, работающих с ними, и по мере необходимости сотворения приложений, работающих с сервером БД.
Для обработки установок юзера либо операторов программ в СУБДП употребляются интерпретаторы установок
(операторов) и компиляторы
. При помощи компиляторов в ряде СУБДП можно получать исполняемые автономно приложения-ехе-программы.
Обеспечение целостности БД-необходимое условие удачного функционирования БД. Целостность БД-свойство БД, значащее, что база данных содержит полную и непротиворечивую информацию, Для обеспечения целостности БД накладывают ограничения целостности в виде неких критерий, которым должны удовлетворять хранимые в базе данные. Примером таковых критерий может служить ограничение диапазонов вероятных значений атрибутов объектов, сведения о которых хранятся в БД, либо отсутствие циклических записей в таблицах реляционных БД.
Обеспечение сохранности
достигается СУБД шифрованием прикладных программ, данных, защиты паролем, поддержкой уровней доступа к базе данных, к отдельной таблице.
расширение способностей юзера СУБДП получается из-за подключения систем распространения Си либо Ассемблера.
Поддержка функционирования в сети обеспечивается:
— средствами управления доступом юзеров к вместе применяемым данным, т.е. средствами блокировки файлов (таблиц), записей, полей, которые в разной степени реализованы в различных СУБДП;
— средствами механизма транзакций, обеспечивающими целостность БД при функционировании в сети.
сейчас разглядим функции СУБД
незначительно подробнее:
Определение данных.
СУБД обязана допускать определения данных (наружные схемы, концептуальную схему, внутреннюю схему, также все связанные отображения) в начальной форме и преобразовывать эти определения в форму соответственных объектов. По другому говоря, СУБД обязана включать в себя компонент языкового микропроцессора для разных языков определений данных. СУБД обязано также «осознавать» синтаксис языка определений данных.
Обработка данных.
СУБД обязана уметь обрабатывать запросы юзера на подборку, изменение либо удаление имеющихся данных в базе данных либо на добавление новейших данных в базу данных. Иными словами, СУБД обязана включать в себя компонент микропроцессора языка обработки данных.
Запросы языка обработки данных бывают «планируемые» и «не планируемые».
1. Планируемый запрос-это
запрос, необходимость которого предусмотрена заблаговременно. админ базы данных, может быть, должен настроить физический проект БД таковым образом, чтоб гарантировать достаточное быстродействие для таковых запросов.
2.
Не планируемый запрос-это,
напротив, особый запрос, необходимость которого не была предусмотрена заблаговременно. Физический проект БД может подступать, а может и не подступать для рассматриваемого специального запроса. В общем, получение вероятной большей производительности для не планируемых запросов представляет собой одну из заморочек СУБД. (Подробнее эта неувязка будет дискуссироваться в последующих частях книжки.)
Сохранность и целостность данных.
СУБД обязана надзирать пользовательские запросы и пресекать пробы нарушения правил сохранности и целостности, определенные АБД.
Восстановление данных и дублирование.
СУБД либо иной связанный с ней программный компонент, обычно именуемый админом транзакций, должны производить нужный контроль над восстановлением данных и дублированием. Подробности использования этих функций системы приводятся дальше в данной книжке.
Словарь данных.
СУБД обязана обеспечить функцию словаря данных
. Сам словарь данных можно по праву считать БД (но не пользовательской, а системой). Словарь «содержит данные о данных» (время от времени именуемые метаданными
), т.е. определения
остальных объектов системы, а не попросту «сырые данные». А именно, начальная и объектная формы разных схем (наружных, концептуальных и т.д.) и отображений будут сохранены в словаре. Расширенный словарь будет включать также перекрестные ссылки, показывающие, к примеру, какие из программ какую часть БД употребляют, какие отчеты требуются тем либо другим юзерам, какие терминалы подключены к системе и т.д. Словарь быть может (а по сути даже должен быть) интегрирован в определяемую им БД, а означает, должен содержать описание самого себя. Естественно, обязано быть возможность воззвания к словарю, как и к иной БД, к примеру, для того выяснить, какие программки и/либо юзеры будут затронуты при предполагаемом внесении конфигурации в систему. (Предстоящее обсуждение этого вопросца приводится в последующих главах книжки.)
Производительность.
Разумеется, что СУБД обязана делать все обозначенные функции с очень вероятной эффективностью.
Подводя результат произнесенному, можно прийти к выводу, что в целом предназначением СУБД является предоставление пользовательского интерфейса
с БД. Пользовательский интерфейс быть может определен как граница в системе, ниже которой все невидимо для юзера. Как следует, по определению пользовательский интерфейс находится на наружном уровне. Тем не наименее, время от времени встречаются случаи, когда наружное системы, которая управляет хранимыми файлами; проще говоря, она «поближе к диску», чем СУБД. Таковым образом, юзер системы управления файлами может создавать и уничтожать хранимые файлы, также делать обыкновенные операции подборки и обновления хранимых записей в таковых файлах. Но, в отличие от СУБД, системы управления файлами имеют некие недочеты.
2. Многофункциональные способности СУБД.
Управляющим компонентом почти всех СУБД является ядро, выполняющее последующие функции:
— управление данными во наружной памяти;
— управление буферами оперативки (рабочими областями, в которые осуществляется подкачка данных из базы для увеличения скорости работы);
— управление транзакциями.
1.
Конкретное управление данными во наружной памяти.
Эта функция включает обеспечение нужных структур наружной памяти, как для хранения данных, конкретно входящие в базу данных так и для служебных целей. к примеру, для ускорения доступа к данным в неких вариантах (обычно для этого употребляется индекс).
В неких реализациях СУБД интенсивно употребляется возможность имеющихся файловых систем. В остальных работа делается прямо до уровня устройств наружной памяти. Но подчеркнем, что в развитых СУБД юзер в любом случае не должен знать внедрение СУБД файловую систему и если употребляет, то, как организованные файлы. А именно СУБД поддерживает свою систему и наименование объектов баз данных.
2.
Управление буторами оперативки.
СУБД обычно работает с БД, по последней мере, этот размер обычно существует, больше доступен размеру оперативки. Что если при воззвании к хоть какому элементу данных будет выполняться размер с наружной памятью, то вся система будет работать со скоростью устройства наружной памяти. Практическим единственным методом реально повышение данной скорости является буферизация данных в оперативки. При всем этом даже если операционная система производит общесистемную буферизацию. Этого не довольно для цели СУБД, которая располагает еще больше инфы о полезности буферизации, т.е. той либо другой части БД. Потому в развитых СУБД поддерживается свой набор буферов оперативки, своей дисциплины подмены буферов. Заметим, что есть отдельные направления СУБД, которые ориентированно, но повсевременно находятся в оперативки БД. Это направление основывается на предположение, что на столько велик, что дозволит, не волнуется о буферизации. (Пака эта работа находится в стадии развития).
3.
Управление транзакциями.
Транзакция – это последовательность операций над БД, рассматриваемая СУБД как единое целое. При выполнении транзакция быть может или удачно завершена, и СУБД зафиксирует произведенные конфигурации во наружной памяти, или, к примеру, при нарушении в аппаратной части ПК , ни 1-го из конфигураций не отразится в БД. понятие транзакция нужно для поддержания логической целостности БД. Таковым образом, поддержание механизма транзакции является неотклонимым условием даже однопользовательских СУБД. (Если таковая система заслуживает СУБД). Но понятие транзакция еще наиболее принципиально много юзер СУБД, то свойство, то любая транзакция начинается при целостном состоянии БД и оставляет это состояние целостное опосля собственного окончания, делает весьма комфортным, внедрение понятие транзакция как единицы активности юзера по отношению БД. При соответственном управлении управляющимися транзакциями со стороны СУБД каждым внедрением может в принципе чувствовать себя единственным юзером СУБД. Управление транзакции многопользовательской СУБД соединены принципиальные понятия сериализация транзакции и сериального плана выполнения консистенции транзакции. Под стерилизацией выполнении параллельно сериализация соображают таковой порядок планирования их работ при которой суммарный эффект консистенции транзакции эквивалентен эффекту их некого поочередного управления. Сериальный план выполнения консистенции транзакции это таковой план, который приводит к сериализация транзакции. Что если удается достигнуть реального сериального выполнения консистенции транзакции, то для всякого юзера по инициативе, которой образованна транзакция присутствие остальных транзакций будет неприметно (если не считать некого замедления работы по сопоставлению с одно использованием режимом). Существует несколько базисных алгоритмов сериализация транзакции. Централизованных СУБД более всераспространены методы, основанные на синхронизации захвата объектов БД. При использовании хоть какого метода вероятная ситуация конфликта меж 2-мя либо наиболее транзакциями по доступу объекта БД. В этом случае для поддержания сериализация нужны, делать откат одной ли наиболее транзакции. Это один из случаев, когда юзер многопользовательской СУБД может реально (и довольно неприятно) почувствовать присутствие в системе транзакции остальных юзеров.
4.
Архитектура СУБД.
Три уровня архитектуры.
Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и наружный. В общих чертах они представляют собой последующее:
— Внутренний уровень-это уровень, более близкий к физическому хранению, т.е. связанный со методами сохранения инфы на физических устройствах хранения.
— Наружный уровень более близок к юзерам, т.е. он связан со методами представления данных для отдельных юзеров.
— 
Концептуальный уровень-это «промежный» уровень меж 2-мя первыми.
Наружный уровень (личные представления юзеров).
Концептуальный уровень (обобщенное Внутренний уровень (памяти).
Если наружный уровень с персональными представлениями юзеров, то концептуальный уровень связан с обобщенным представлением юзеров. По другому говоря, быть может несколько наружных представлений, каждое из которых состоит из наиболее либо наименее абстрактного представления определенной части БД, и быть может лишь одно концептуальное юзер быть может прикладным программером либо конечным юзером с хоть каким уровнем проф подготовки. Особенное пространство посреди юзеров занимает админ БД. (В отличие от других юзеров его интересует также концептуальный и внутренний уровень.)
У всякого юзера есть собственный язык общения.
— Для прикладного программера это или один из всераспространенных языков программирования, таковой как C, COBOL либо PL/1, или особый язык рассматриваемой системы. Такие уникальные языки именуют (неформально!) языками 4-ого поколения на том основании, что машинный код, язык ассемблера и такие языки, как COBOL, можно считать языками 3-х первых «поколений», а уникальные языки модернизированы по сопоставлению с языками третьего поколения так же, как языки третьего поколения усовершенствованы по сопоставлению с языком ассемблера.
— Для конечного юзера это либо особый язык запросов, либо язык специального предназначения, может быть, основанный на формах и меню, сделанный специально с учетом требований и поддерживаемый неким оперативным приложением.
Хотя исходя из убеждений архитектуры комфортно различать подъязык данных и включающий его базисный язык, на практике они могут быть неразличимыми так, как это имеет отношение к юзеру. Непременно, сточки зрения юзера, лучше, чтоб они неразличимы либо тяжело различимым, их именуют очень связанными. Если они ясно и просто различаются, молвят, что они слабо соединены. Большая часть систем на нынешний денек поддерживает только слабенькую связь. Система с мощной связью могли бы предоставить юзеру наиболее унифицированный набор способностей, но, разумеется, требуют больше усилий со стороны системных проектировщиков и разрабов (которые, возможно, рассчитывают на статус-кво); но есть основания полагать, что в протяжении последующих нескольких лет будет происходить постепенное продвижение к наиболее очень связанным системам.
язык обработки данных состоит из таковых выполняемых операторов PL/1, которые передают информацию в
и из
БД; снова же, может быть, включая, новейшие особые операторы.
В общем, наружное к примеру, операция подборки языка обработки данных будет проводить подборку из экземпляров наружных, а не хранимых записей.
Концептуальный уровень.
Концептуальное несколько наиболее абстрактной форме (как и случае наружного представления) по сопоставлению с физическим методом хранения данных. Но концептуальное юзер в рамках, к примеру, определенного языка либо применяемого аппаратного обеспечения.
Концептуальное к примеру, оно может состоять из набора экземпляров записей, содержащих информацию о отдельных, плюс набор экземпляров, содержащих информацию о деталях и т.д. Мировозренческая запись совсем не непременно обязана совпадать с наружной записью, с одной стороны, и с хранимой записью- с иной.
Концептуальное определения всякого типа концептуальных записей. Мировозренческая схема употребляет иной язык определения данных — концептуальный.
Концептуальное больше напоминающих обыкновенные дела записей в программке на языке COBOL (либо каком-либо другом).
сейчас перейдем к наиболее детальному исследованию 3-х уровней архитектуры.
Внутренний уровень.
Третьим уровнем архитектуры является внутренний уровень. Внутреннее термин «внутренняя запись» принадлежит терминологии ANSI/SPARC и значит систему, именуемую хранимой записью. Внутреннее области устройства хранения, такие как цилиндры и дорожки. Иными словами, внутреннее системы и специально не включены в общую архитектуру.
Внутреннее методы представления хранимых полей, физическую последовательность хранимых записей и т.д. Внутренняя схема пишется с внедрением еще 1-го языка определения данных – внутреннего.
В заключении отметим, что в неких исключительных ситуациях прикладные программки, а именно те, которые именуют утилитами могут делать операции конкретно на внутреннем, а не на наружном уровне. естественно, таковой практикой воспользоваться не рекомендуется; она описывает риск исходя из убеждений сохранности (правила сохранности игнорируются ) и целостности (правила целостности тоже игнорируется), к тому же программка будет зависеть от загруженных данных; но время от времени это быть может единственным методом достигнуть выполнения требуемой функции либо достигнуть нужного быстродействия – так же, как юзеру языка высочайшего уровня время от времени по этим же причинам нужно прибегнуть к языку ассемблера.
Приложения, использующие базы данных, обычно принято относить к одной из программных архитектур, имеющих свои плюсы и минусы.
локальная архитектура
.
И программка, и база данных размещены на одном компе. В таковой архитектуре работает большая часть настольных приложений.
файл – серверная архитектура.
база данных размещена на массивном выделенном компе (сервере), а индивидуальные компы подключены к нему по локальной сети. На этих компах установлены клиентские программки, обращающиеся к базе данных по сети. Преимущество таковой архитектуры заключается в способности одновременной работы нескольких юзеров с одной базой данных.
Недочет такового подхода — огромные объемы инфы, передаваемой по сети. Вся обработка производится на клиентских местах, где практически формируется копия базы данных. Это приводится к ограничению очень вероятного числа юзеров и огромным задержкам при работе с базой. Эти задержки вызываются тем, что на уровне определенной таблицы одновременный доступ неосуществимый. Пока программка на одном из клиентских мест не окончит работу с таблицей (к примеру, не выполнит модификацию записей), остальные программки не могут обращаться к данной таблице. Это именуется блокировкой на уровне таблицы и исключает появление неурядицы в ее содержимом.
клиент – серверная архитектура
.
В таковой архитектуре на сервере не только лишь хранится БД, да и работает программка СУБД, обрабатывающая запросы юзеров и возвращающая им наборы записей. При всем этом программки юзеров уже не работают, к примеру, с БД как набором физических фалов, а обращаются к СУБД, которая делает операции. Перегрузка с клиентских мест при всем этом снимается, потому что большая часть работы происходит на сервере. СУБД автоматом смотрит за целостностью и сохранностью БД, также контролирует доступ к инфы при помощи службы паролей. клиент – серверные СУБД допускают блоки на уровне записи
и даже отдельного поля.
Это значит, что с таблицей может работать хоть какое число юзеров, но доступ к функции конфигурации определенной записи либо 1-го из ее полей обеспечен лишь одному из их.
Главный недочет данной архитектуры не весьма высочайшая надежность. Если выходит из строй, вся работа останавливается.
Распределенная архитектура.
В сети работает несколько серверов, и таблицы баз данных распределены меж ними для заслуги завышенной эффективности. На любом сервере работает своя копия СУБД. Не считая того, в схожей архитектуре обычно употребляются особые программки, так именуемые серверы приложений
. Они разрешают улучшить обработку запросов огромного числа юзеров и умеренно распределить нагрузку меж компами в сети.
Недочет распределенной архитектуры заключается в достаточно сложном и дорогостоящем процессе ее сотворения и сопровождения (администрирования), также а больших требованиях к сервером компам.
веб – архитектура.
Доступ к базе данных и СУБД (всераспространенных на одном компе либо в сети) осуществляется из броузера по обычному протоколу. Это предъявляет малые требования к клиентскому оборудованию. Такие программки именуют «тонкими клиентами», поэтому что они способны работать даже на ПК с микропроцессором 80386. Благодаря стандартизации всех протоколов и внедрять. к примеру, можно не организовывать локальную сеть, а обращаться к серверу через Веб в локальной сети (в таком случае молвят о разработках интранет). В этом случае не требуется разрабатывать особые клиентские программки либо выдумывать собственные спецификации обмена данными меж сервером и клиентскими местами. Довольно употреблять готовые броузера и программные решения.
4. Типы СУБД.
Системой управления базами данных именуют программную систему, созданную для сотворения на ЭВМ общей базы данных для огромного количества приложений, поддержания ее животрепещущем состоянии и обеспечения эффективности доступа юзеров к содержащимся в ней данным в рамках предоставленных им возможностей. СУБД предназначена, таковым образом, для централизованного управления БД как соц ресурсом в интересах всей совокупностей ее юзеров. Доступ к базе данных отдельных юзеров при всем этом вероятен лишь через посредство СУБД.
По степени их универсальности различаются два вида СУБД – системы общего предназначения
и спец
системы. СУБД общего предназначения не ориентированны на какую – или определенную предметную область либо на информационные потребности определенной группы юзеров. Любая система такового рода реализуется как программный продукт, способный работать на некой модели ЭВМ в определенной обстановки, и поставляется почти всем юзерам как коммерческое изделие. СУБД общего предназначения владеют средствами опции на работу с определенной БД в критериях определенного внедрения.
Внедрение СУБД общего предназначения в качестве инструментального средства для сотворения автоматических информационных систем, основанных на технологии БД, дозволяет значительно сокращать сроки разработки, сберегать трудовые ресурсы. Развитые многофункциональные способности таковых СУБД, присущая им, как правило, многофункциональная избыточность разрешают иметь значимый «припас мощности», нужный для безболезненного эволюционного развития построенных на их базе информационных систем в рамках их актуального цикла. совместно с тем средства опции дают возможность добиться применимого уровня производительности информационной системы в процессе ее эксплуатации.
Но в неких вариантах доступные СУБД общего предназначения не разрешают достигнуть требуемых черт производительности и/либо удовлетворить данные ограничения по размеру памяти, предоставляемой для хранения БД. Тогда приходится разрабатывать специализированную СУБД для данного определенного внедрения. Решение обозначенных заморочек при всем этом может оказаться вероятным благодаря познанию специфичных особенностей данного внедрения, к которым оказываются нечувствительными средства опции доступных СУБД общего предназначения, или за счет ущемления каких или функций системы, не имеющих актуально принципиального значения. Как правило, в данной роли оказываются, до этого всего функции, обеспечивающие удобную работу юзера.
Создание спец СУБД – очень трудоемкое дело даже в сравнимо обычных вариантах, и для того, чтоб выбрать этот путь, необходимо иметь вправду весомые основания и твердую убеждаемость в невозможности либо нецелесообразности использования какой – или СУБД общего предназначения.
СУБД общего предназначения – это сложные программные комплексы, созданные для выполнения всей совокупы функций, связанных с созданием и эксплуатацией БД информационной системы. Они разрешают найти структуру создаваемой БД, инициализировать ее и произвести исходную загрузку данных. Системные механизмы делают также функции управления ресурсами среды хранения, обеспечения логической и физической независимости данных, предоставления доступа юзерам к БД, защиты логической целостности БД, обеспечения ее физической целостности – защиты от разрушений. Иная принципиальная группа функций – управления возможностями юзеров на доступ к БД, настройка на определенные условия внедрения, организация параллельного доступа юзеров к базе данных в социальной пользовательской среде, поддержка деятель системного персонала, ответственного за эксплуатацию БД.
Для сотворения БД разраб обрисовывает ее логическую структуру, компанию в среде хранения, также методы видения базы данных юзерами. При всем этом употребляются предоставляемые СУБД языковые средства определения данных, и система настраивается на работу с определенной БД. Такие описания БД именуются соответственно схемой
(либо логической схемой, либо концептуальной схемой) БД, схемой хранения
(либо внутренней схемой) и наружными схемами
.
Обрабатывая схемы БД, СУБД делает пустую БД требуемой структуры – хранилище, которое можно дальше наполнить данными о предметной области начать эксплуатировать для ублажения информационных потребностей юзеров.
Принципно принципиальное свойство СУБД состоит в том, что она дозволяет различать и поддерживать два независящих взора на БД – взор юзера, воплощаемой в «логическом
» представлении данных, и «взор» системы – «физическое
» представление, характеризующее компанию хранимых данных. Юзера не интересует при его работе с БД байты и биты, представляющие данные в среде хранения, их размещения в памяти, указателя, поддерживающие связи меж структурными разными компонентами хранимых данных, избранные способы доступа. В то же время эти причины важны для выполнения функций управления данными самой СУБД.
Обеспечение логической независимости данных
– одна из важных функций СУБД, предоставляющая определенную степень свободы варианты «логического» представления БД без необходимости соответственной модификации «физического» представления. Благодаря этому достигается возможность адаптации взора юзера на БД к его настоящим потребностям, конструирования разных «логических» взглядов на одну и ту же «физическую» БД, что очень принципиально в социальной пользовательской среде.
Под «физической» независимостью данных
понимается способность СУБД предоставлять некую свободу модификации методов организации БД в среде хранения, не вызывая необходимости внесения соответственных конфигураций в «логическое» системы с целью увеличения ее эффективности, не затрагивая сделанных прикладных программ, использующих базу данных. «Физическая» независимость данных реализуется в СУБД за счет тех же самых трансформационных устройств архитектуры системы, которые обеспечивают «логическую» независимость данных.
Поддержка логической целостности (непротиворечивости) базы данных – иная принципиальная функция СУБД. В развитых системах ограничения целостности базы данных объявляются в схеме базы данных, и их проверка осуществляется при любом обновлении объектов данных либо связей меж ними, являющихся аргументами таковых ограничений.
Глава 2. Разработка базы данных по рынку бытовой химии.
Процесс разработки (проектирования) базы данных включает два шага: разработку логической организации базы данных и создание ее на носителе. Логическая организация базы данных – это предоставление юзера о предметной области, информация о которой обязана храниться в базе данных. Под физической организацией базы данных понимается совокупа средств и способов размещения данных во наружной памяти и на их базе внутренняя модель данных. Внутренняя модель является средством отображения логической модели данных, указывает, каким образом записи располагаются в базе данных, как они упорядочиваются, как организуются связи, каким методом можно выполнить подборку и так дальше.
В истинное время разработаны и употребляются на индивидуальных компах около 20 систем управления базами данных. Они представляют юзеру комфортные средства интерактивного взаимодействия с БД и имеют развитый язык программирования. Одной из самых фаворитных настольных программных СУБД является MicrosoftAccess.
одной из главных обстоятельств таковой популярности Access состоит в том, что, является на самом деле настольной СУБД, это приложение вобрало в себя почти все способности систем управления реляционными базами данных архитектуры клиент-сервер, именуемой также SQL базой данных. Невзирая на то, что, Access содержат в себе сложные функции и может послужить красивым инвентарем для проф разраба приложений БД, его внедрение не обязано вызвать заморочек и у непрофессиональной юзеров и даже тех, кто ранее не работал с СУБД. Клавиши на панелях инструментов дублируют главные команды меню, расширенный набор мастеров и опций управляет фактически всеми параметрами сотворения и конфигурации объектов БД (таблиц, форм, отчетов, запросов и т.д.). При помощи ACCESS можно создавать многопользовательских приложений, в каких файлы базы данных являются разделяемыми ресурсами в локальной сети. В ACCESS реализованного доступа к объектам базы данных. MicrosoftAccess для хранения объектов БД имеет свою неповторимую структуру для хранения всех связанных таблиц, форм, отчетов, запросов и макрософт в одном файле. Также имеет возможность импорта и экспорта данных во почти все широкие всераспространенные форматы БД, электрических таблиц и текстовых файлов. ACCESS дозволяет связывать БД с наружными таблицами в форматах dBase, FoxPro, Paradox и работать с ними в начальном формате. Также Access можно употреблять в качестве клиентской части архитектуры клиент-сервер, что обеспечивает применение MicrosoftAccess не только лишь в качестве проф системы управления базы данных, да и как массивное инструментальное средство для сотворения приложений клиент-сервер.
База данных по бытовой технике городка Улан-Удэ была разработана в программке MicrosoftAccess. Вся нужная информация представлена в 2-ух таблицах. Таблица базы данных – это совокупа сведений. Так, к примеру, в таблице «торговые салоны» отображена информация о торговом салоне, адресе, телефоне (рис. 1), а в таблице «продукты» — информация о предоставляемых торговым салоном товарах (рис. 2). Каждое поле предоставляет собой столбец таблицы и содержит определенную категорию инфы. Любая запись предоставляет собой строчку таблицы и содержит информацию о определенном товаре. Можно сделать связи меж таблицами (Рис. 10), заместо того, чтоб хранить всю информацию в одной большенный таблице, избегая тем ненадобного дублирования данных, экономии памяти компа, также повышение скорости и точности обработки инфы. Так, к примеру, любая запись в таблице «все продукты» содержит информацию о фирме и предоставляемых ею товарах (рис. 3). Запросы употребляются приблизительно также, как и таблицы. Вы сможете открыть запрос и просмотреть набор данных в табличном представлении. При разработке запроса указываются таблицы, из которых будет делается подборка данных, указываются поля таблицы, которые должны быть внесены в итог запроса, обозначено условие отбора данных. В данном случае при выбирании запроса «поиск по салону» (рис. 4), указав заглавие салона, вы получите интересующую вас информацию о товарах в этом салоне.
При выбирании запроса «поиск по товарам» (рис. 3) вы получите информацию о представляемых компанией товарах.
При помощи форм можно показывать данные, находящиеся в таблицах либо запросах, в еще наиболее комфортное для восприятия виде. С помощью форм можно добавлять в таблицы новейшие данные либо изменять и удалять имеющиеся. Форма может содержать картинки, графики и остальные объекты. Формы создаются из набора отдельных частей, именуемых органами управления (графический объект для предоставления данных). Форму для предоставления данных MicrosoftAccess предоставляет автоматом. Опосля ее наполнения можно просмотреть информацию вполне либо отчасти с помощью процедур поиска, запроса, сортировки. Для просмотра нужной инфы при помощи форм в моей базе данных представлены 6 разных форм: кнопочная, все продукты, все торговые салоны, поиск, поиск по салону, поиск по товару (рис. 5-10). При выбирании той либо другой формы, указав, если есть необходимость, заглавие продукта, вы получите интересующую вас информацию.
Заключение.
Таковым образом, БД является важной составной частью информационных систем, которые предусмотрены для хранения и обработки инфы. Вначале такие системы существовали в письменном виде. Для этого использовались разные картотеки, папки, журнальчики, библиотечные сборники. Развитие средств вычислительной техники обеспечило возможность для сотворения и широкого использования автоматических информационных систем. Разрабатываются информационные системы для обслуживания разных систем деятельности, системы управления хозяйственными и техническими объектами, модельные комплексы для научных исследовательских работ, системы автоматизации проектирования и производства, различные тренажеры и обучающие системы. Современные информационные системы основаны на концепции интеграции данных, характеризующих большенными объектами хранимых данных, сложной организацией, необходимостью удовлетворять различные требования бессчетных юзеров. Для управления этими данными и обеспечения эффективности доступа к ним были сделаны системы управления данными.
Таковым образом, СУБД именуют программную систему, созданную для сотворения ЭВМ общей базы данных для огромного количества приложений, поддержания ее в животрепещущем состоянии и обеспечения эффективности доступа юзеров к содержащимся в ней данным в рамках предоставленных им возможностей.
Приведенная для примера база данных по бытовой химии городка Улан-Удэ разработана в программке MicrosoftAccess, которая является одной из самых фаворитных посреди настольных программных систем управления базами данных. Посреди обстоятельств таковой популярности необходимо подчеркнуть:
— высшую степень универсальности и продуманности интерфейса, который рассчитан на работу с юзерами самой различной квалификации. А именно, реализована система управления объектами базы данных, позволяющая гибко и оперативно перебегать из режима конструктора в режим их конкретной эксплуатации;
— глубоко развитые способности интеграции с иными программными продуктами, входящими в состав MicrosoftOffice, также с хоть какими программками продуктами, поддерживающими технологию OLE;
— обеспеченный набор зрительных средств разработки.
Перечень литературы:
1. С. Бобровский С.- П. 2001г. «DELPHI 5».
2. А.Д. Хоменко «Базы современных компьютерных технологий». М. 2000г.
3. А.Я.Архангальский «Программирование в Delphi 5» М. 2000г.
4. Ю. Бекаревич, Н.Пушкина «MSACCESS 2000 ЗА 30 занятий».
5. С.Н.Кандзюба, В.Н.Громова «DELPHI 5».
6. Марко Кэнту «DELPHI 5».
7. В.Гофман, А.Хаменко «Работа с БД в DELPHI».
8. К.Дэйт «Введени
9. Введение в системы баз данных» К.2000г.
10. СУБД MicrosoftAccess 2.0 “Шаг за шагом» М. 1995г.
Министерство Культуры РФ (Российская Федерация — Кафедра
МиМИД
Курсовая работа
Тема:
Разработка базы данных по товарам потребительского рынка бытовой технике.
Выполнила студент 2
курса
Очного отделения 425
группы
Специальность 071900 «Информационные
системы в социально-культурной сфере»
Квалификация «Менеджер
Информационных систем»
Перевалов Станислав Николаевич
Научный управляющий
Иванова Надежда Сергеевна
Работа сдана на рецензию «_____»______________________2002г. Допущена к защите «_____»____________________________2002г.
Защищена с оценкой ___________________________
Улан-Удэ
2002г.
]]>