Учебная работа. Реферат: Система управления баз данных

(Пока оценок нет)

Загрузка...

Учебная работа. Реферат: Система управления баз данных

СУБД (система управления баз данных) — программный комплекс, созданная для сотворения, введения и использования баз данных.

систематизация СУБД:

· иерархические

· сетевые

· реляционные

· объектно-ориентированные

1. Иерархические БД

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

Главными информационными единицами в иерархической модели данных являются сектор и поле. Поле данных определяется как меньшая неразделимая единица данных, доступная юзеру. Для сектора определяются тип сектора и экземпляр сектора. Экземпляр сектора появляется из определенных значений полей данных. Тип сектора — это поименованная совокупа входящих в него типов полей данных. Как и сетевая, иерархическая модель данных базируется на графовой форме построения данных, и на концептуальном уровне она является просто личным случаем сетевой модели данных. В иерархической модели данных верхушке графа соответствует тип сектора либо просто сектор, а дугам — типы связей предок — потомок. В иерархических структуpax сектор — потомок должен иметь в точности 1-го предка. Иерархическая модель представляет собой связный неориентированный гpaф древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из упорядоченного набора деревьев.

В рамках иерархической модели выделяют языковые средства описания данных (ЯОД) и средства манипулирования данными (ЯМД). Любая физическая база описывается набором операторов, обусловливающих как ее логическую структуру, так и структуру хранения БД. При всем этом метод доступа устанавливает метод организации связи физических записей.

Определены последующие методы доступа:

· иерархически поочередный;

· иерархически индексно-последовательный;

· иерархически прямой;

· иерархически индексно-прямой;

· индексный.

Кроме задания имени БД и метода доступа описания должны содержать определения типов частей, составляющих БД, в согласовании с иерархией, начиная с корневого сектора. Любая физическая БД содержит лишь один корневой сектор, но в системе быть может несколько физических БД.

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

Иерархической базой данных является
, с которым можно работать, запустив Проводник. Верхний уровень занимает комп, Мои документы, Сетевое свита
и
, которые являются потомками папки
, а меж собой является близнецами. В свою очередь, диск 3,5(А:), (С:), (D:), (Е:), (F:)
) и системным папкам (
и др.)

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

Содержание реестра автоматом обновляется при установке новейшего оборудования, установки программ и т. п. Для просмотра и редактирования реестра Windows в ручном режиме можно применять специальную программку rege-dit.exe, которая хранится в папке Windows. Но редактирование реестра можно проводить лишь в случае последней необходимости и при условии осознания выполняемых действий. Неквалифицированное редактирование реестра может привести комп в неработоспособное состояние.

Еще одним примером иерархической базы данных является база данных
присоединенных к Вебу компов. На верхнем уровне находится табличная база данных, содержащая список доменов верхнего уровня (всего 264 домена), из которых 7 — административные, а другие 257 — географические. Более большим доменом (данные на январь 2002 года) является домен net (около 48 миллионов серверов), а в неких доменах (к примеру, в домене zr) до сего времени не записанно ни 1-го сервера.

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

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

База данных
обязана содержать записи обо всех компах, присоединенных к Вебу, другими словами наиболее 150 миллионов записей. Размещение таковой большой базы данных на одном компе сделало бы поиск инфы весьма неспешным и неэффективным. Решение данной нам задачи было найдено методом размещения отдельных составных частей базы данных на разных DNS-серверах. Таковым образом, иерархическая база данных
является
.

Поиск инфы в таковой иерархической распределенной базе данных ведется последующим образом. к примеру, мы желаем ознакомиться с содержанием WWW-сервера компании Microsoft.

Поначалу наш запрос, содержащий доменное имя сервера www.microsoft..com, будет оправлен на DNS- нашего провайдера, который переадресует его на DNS- самого верхнего уровня базы данных. В таблице первого уровня будет найден интересующий нас домен com и запрос будет адресован на DNS-сервер второго уровня, который содержит список доменов второго уровня, зарегистрированных в домене com.

В таблице второго уровня будет найден домен microsoft и запрос будет переадресован на DNS- третьего уровня. В таблице третьего уровня будет найдена запись, соответственная доменному имени, содержавшемуся в запросе. Поиск инфы в базе данных
будет завершен и начнется поиск компа в сети по его IP-адресу.

2. Сетевые БД

Сетевая СУБД
— система управления базами данных, поддерживающая сетевую компанию: неважно какая запись, именуемая записью старшего уровня, может содержать данные, которые относятся к набору остальных записей, именуемых записями подчиненного уровня.

Обычным представителем является Integrated Database Management System возникла в 70-х годах. Сетевой подход к организации данных является расширением иерархического. Сетевая БД состоит из набора записей и набора связей меж этими записями. На формирование связи особенных ограничений не накладывается. В иерархических структурах запись-потомок обязана иметь в точности 1-го предка; в сетевой структуре данных потомок может иметь хоть какое число протцов. Достоинством сетевой модели данных является возможность действенной реализации по показателям издержек памяти и оперативности. В сопоставлении с иерархической моделью сетевая модель предоставляет огромные способности в смысле допустимости образования случайных связей. В рамках сетевых СУБД просто реализуются и иерархические даталогические модели. Сетевые СУБД поддерживают сложные соотношения меж типами данных, что делает их подходящими в почти всех разных приложениях. Но юзеры таковых СУБД ограничены связями, определенными для их разрабами БД-приложений. Наиболее того, подобно иерархическим сетевые СУБД подразумевают разработку БД приложений опытнейшеми программерами и системными аналитиками.

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

Просматривая, например, в сетевой СУБД записи объекта «Лицо» и выбрав запись «Иванов» (т. е. поместив табличный курсор на подобающую запись), можно через активизацию поля «Работает» вызвать на экран поля связанной записи в объекте «Организация» и просмотреть надлежащие данные, а дальше, по мере необходимости, через активизацию поля «Адресок» в записи по объекту «Организация» вызвать и просмотреть данные по дислокации места работы сотрудника «Иванов» и т. д.

Данный пример указывает, что
разрешают юзеру реализовывать свои
(«беседовать» с базой данных) наиболее
шаг за шагом уточняя свои потребности, и тем наиболее глубоко и наглядно рассматривать (учить) данные.

3. Реляционные БД

К.Дейт в собственной традиционной книжке «Введение в системы баз данных» дает последующее определение реляционной системы управления базами данных:

1. Данные воспринимаются юзером как таблицы (и никак по другому).

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

одна из конкретных задач СУБД (тут и дальше речь идет о реляционных СУБД, потому слово «реляционный» опускается) — производить контроль целостности данных. Под целостностью данных предполагается логическая непротиворечивость данных. Различают три понятия целостности:

1. Целостность в отношении определенной базы — такие данные, как возраст, рост, вес не могут быть отрицательными. IP-адресок имеет строго данный формат — это четыре числа в спектре от 0 до 255, разбитых точкой, плюс доп ограничения на внедрение 0, 255 и спецадресов. Большая часть СУБД не предоставляют устройств, полностью позволяющих надзирать данный тип целостности.

2. Целостность сущностей — в таблице, где хранятся записи о объектах, не быть может 2-ух схожих объектов, также не быть может неопределенных объектов, т.е. записей с неопределенным значением (NULL-значением) первичного ключа. СУБД не обязана допускать записей с циклическими значениями первичного ключа либо NULL-значением 1-го из компонент первичного ключа. Данный тип целостности поддерживают все СУБД. Наиболее тщательно мы побеседуем о этом понятии целостности ниже, при описании первичных ключей.

3. Ссылочная целостность — одной записи в таблице гостевых книжек может соответствовать несколько записей в таблице сообщений. Таблицы могут находиться во взаимосвязях один к одному, один ко почти всем и почти все ко почти всем. Связи меж таблицами осуществляются на основании наружных ключей. В таблице сообщений не быть может сообщения, принадлежащего к несуществующей гостевой книжке, по другому говоря, хоть какой записи в таблице сообщений обязана найтись запись в таблице гостевых книжек. СУБД обязана предоставлять механизмы для контроля операций и соблюдения ссылочной целостности при выполнении операций INSERT, UPDATE и DELETE. К огорчению, не все СУБД имеют такие механизмы.

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

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

email varchar(32) CHECK (email LIKE ‘%@%’),

Тем, запретив значения, которые не содержат знака ‘@’. Большая часть же информационных систем применительно к интернет-сайтам, будь то конференции, чаты, списки рассылки, имеют достаточно ординарную структуру базы данных, обычно не превосходящую 5-7 таблиц. В таковых системах целостность данных не имеет критичного значения. В случае ввода неверного адреса электрической почты ничего чертовского не произойдет, потому контроль за целостностью данных можно переложить на приложения, т.е. CGI-программы.
Механизм триггеров дозволяет СУБД надзирать операции INSERT, UPDATE и DELETE на предмет допустимости этих операций. к примеру, таковым образом, вы сможете ограничить число публикуемых сообщений в денек от 1-го юзера либо запретить вводить сообщения, длиной наиболее 255 знаков, лицам, незаполнившим поля email и http.
И в конце концов, крайний механизм транзакций, о котором для вас нужно иметь один из их не будет выполнен. Транзакции могут применятся при вставке, изменении и удалении данных в нескольких таблицах. к примеру, для вас нужно в системе гостевых книжек соединить две гостевые книжки в одну. Для этого нужно поменять идентификатор гостевой книжки gb_id в таблице сообщений, удалить одну запись из таблицы гостевых книжек и, может быть, видоизменять запись о первой гостевой книжке. И мы должны быть вполне убеждены в том, что или эти операции пройдут удачно, или же не будет выполнена ни одна из их.

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

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

Можно выделить принципно различающиеся три варианта:

1. в таблице отсутствует первичный ключ;

2. обычный первичный ключ, т.е. состоящий из 1-го столбца;

3. составной первичный ключ, т.е. состоящий из нескольких столбцов.

Разглядим 1-ый вариант, когда в таблице может и не быть первичного ключа, как, к примеру, в таблице hit в системе анализа гостей веб—веб-сайта. В данной нам таблице просто нет столбцов, которые могли бы образовать первичный ключ. В таблице, чисто на теоретическом уровне, с весьма малой толикой вероятности могут быть вполне схожие строчки. один юзер может запустить на собственном компе два броузера и открыть в их страничку нашего веб-сайта. Из-за того, что ни операционная система, ни протокол TCPIP не работают в настоящем времени, и в их имеются задержки по времени, есть возможность того, что открытие в этих броузерах нашей странички произойдет сразу. Соответственно, так как броузеры одни и те же, работают на одном компе, то программка counter занесет в таблицу hit две схожие строки. Также маленькое пояснение, что CGI-программка counter быть может запущена сразу несколько раз, и что сервер тоже работает не в настоящем времени, потому и есть возможность возникновения схожих строк.
В таблице hit нет необходимости различать записи, т.е. иметь первичный ключ. Если б таковая необходимость была, то можно было бы добавить в таблицу счетчик записей. В СУБД MYSQL это делается последующим образом:

CREATE TABLE hit(

hit_id int(10) unsigned NOT NULL auto_increment,

…

)

При вставке новейшей записи hit_id будет возрастать на единицу, тем мы получим возможность различать записи снутри таблицы. В системе гостевых книжек первичными ключами являются поля gb_id в таблице гостевых книжек и Message_id в таблице сообщений. На практике почаще всего встречается конкретно таковой метод предназначения и использования первичных ключей. В таблицах системы гостевых книжек первичные ключи служат для идентификации записей и установления дела один ко почти всем. В традиционной теории для соблюдения целостности сущностей нужно назначать первичным ключом столбец либо группу столбцов, которые совершенно точно идентифицируют объект. Но в действительности, часто, таковых столбцов может и не быть. Ни в таблице сообщений, ни в таблице гостевых книжек нет осмысленной группы столбцов, которую бы можно было назначить первичным ключом. В данном случае, первичным ключом можно лишь создать все столбцы таблицы сообщений, но, в этом случае, мы осложняем для себя жизнь при выбирании определенного сообщения. В запросе SELECT * FROM Message WHERE name=’name’ AND email=’email’ AND… придется перечислить совпадение для всякого столбца. Таковая подборка будет происходить медлительно, т.к. необходимо затратить время, чтоб выполнить сопоставление для всякого столбца. Еще удобнее ввести счетчик, тогда запрос будет смотреться существенно проще: SELECT * FROM Message WHERE id=’id’.
Если же у вас в таблице имеется все таки столбец либо несколько столбцов, совершенно точно идентифицирующих объект, то их безусловн стоит назначить первичным ключом. к примеру, у вас база данных по карам, в этом случае, первичным ключом будет номер кара. Не стоит пугаться того, что номер кара представляется символьной строчкой. Когда вы назначаете столбец либо группу столбцов первичным ключом, по ним автоматом создается индекс. Индекс представляет собой хеш-таблицу, т.е. таблицу из 2-ух колонок: в первой колонке в отсортированном порядке идут значения первичного ключа, а во 2-ой колонке — указатель на то пространство, где лежит полная запись таблицы. Так как 1-ая колонка отсортирована, то операции поиска по таковой таблице происходят на порядок резвее, чем если б индекса не было. Для всех полей таблицы, которые участвуют в предложении WHERE SQL-запросов, нужно непременно создавать индексы. Но, учтите, что индекс ускоряет поиск лишь в случае, если его значения слабо повторяются. Одним словом, если вы сделаете индекс по полю «пол», то никакого убыстрения не получится, т.к. половина хеш-таблицы будет состоять из одних записей, а половина из остальных. В MySQL индекссоздаетсяследующейкомандой:

CREATE [UNIQUE] INDEX index_name ON tablename (column1, column2, …)

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

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

Дальше мы разглядим типы отношений меж таблицами:

Отношение один ко почти всем
Отношение почти все ко почти всем
Отношение один к одному

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

Мы лицезреем таблицу создателей, которая относится к таблице aa (сокращение от authorarticle), как один ко почти всем. Это значит, что для одной записи в таблице создателей быть может несколько записей в таблице aa. Аналогичным образом и таблица статей относится к таблице aa, как один ко почти всем. А меж таблицами создателей и статей реализуется отношение почти все ко почти всем.

4. Объектно-ориентированные БД

В более общей и традиционной постановке объектно-ориентированный подход базируется на концепциях:

1. объекта и идентификатора объекта;

2. атрибутов и способов;

3. классов;

4. иерархии и наследования классов.

Конкретным предшественником объектно-ориентированных СУБД являются системы, поддерживающие компанию сложных объектов. Эти постреляционные системы большей частью возникли из-за несоответствия способностей реляционных СУБД потребностям нестандартных приложений (автоматизация проектирования, инженерия и т.д.). На самом деле дела, в таковых системах отчасти поддерживается структурная часть ООБД (без способностей наследования). Почти все объектно-ориентированные СУБД (а именно, ORION) разрабатывались на базе прошлых работ со сложными объектами.

иной основой объектно-ориентированных СУБД являются так именуемые расширяемые системы. Основная мысль таковых систем состоит в поддержании набора модулей с верно обсужденными интерфейсами, на базе которого можно стремительно выстроить СУБД, опирающуюся на определенную модель данных либо созданную для определенной области применений. А именно, как указывает опыт системы EXODUS, средства расширяемых систем отлично подходящи и для построения объектно-ориентированной СУБД.

Самую большую многофункциональную нагрузку несет компонент управления объектами. В число функций данной нам подсистемы заходит:

— управление сложными объектами, включая создание и ликвидирование объектов, подборку объектов по именам, поддержку предопределенных способов, поддержку объектов со внутренней структурой-множеством, перечнем и кортежем;

— управление передачей сообщений меж объектами;

— управление транзакциями;

— управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

— отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во наружной памяти до того времени, пока достижим из какого-нибудь долговременно хранимого объекта);

— управление буферами оперативки (аналогично ORION,

СУБД (система управления баз данных) — программный комплекс, {предназначенная для|созданная для} {создания|сотворения}, введения и использования баз данных.

{классификация|систематизация} СУБД:

· иерархические

· сетевые

· реляционные

· объектно-ориентированные

1. Иерархические БД

Могут быть представлены как дерево, состоящее из объектов {различных|разных} уровней. Верхний уровень занимает один объект, {второй|2-ой} — объекты второго уровня и т. д.{Между|Меж} объектами {существуют|есть} связи, {каждый|любой} объект может включать в себя несколько объектов {более|наиболее} низкого уровня. Такие объекты находятся в отношении предка (объект {более|наиболее} близкий к корню) к потомку (объект {более|наиболее} низкого уровня), {при этом|при всем этом} {возможна|вероятна} ситуация, когда объект-предок не имеет потомков {или|либо} имеет их несколько, тогда как у объекта-потомка {обязательно|непременно} {только|лишь} один предок. Объекты, имеющие общего предка, {называются|именуются} близнецами.

{Основными|Главными} информационными единицами в иерархической модели данных являются {сегмент|сектор} и поле. Поле данных определяется как {наименьшая|меньшая} {неделимая|неразделимая} единица данных, доступная {пользователю|юзеру}. Для {сегмента|сектора} определяются тип {сегмента|сектора} и экземпляр {сегмента|сектора}. Экземпляр {сегмента|сектора} {образуется|появляется} из {конкретных|определенных} значений полей данных. Тип {сегмента|сектора} — это поименованная {совокупность|совокупа} входящих в него типов полей данных. Как и сетевая, иерархическая модель данных базируется на графовой форме построения данных, и на концептуальном уровне она является просто {частным|личным} случаем сетевой модели данных. В иерархической модели данных {вершине|верхушке} графа соответствует тип {сегмента|сектора} {или|либо} просто {сегмент|сектор}, а дугам — типы связей предок — потомок. В иерархических структуpax {сегмент|сектор} — потомок должен иметь в точности {одного|1-го} предка. Иерархическая модель представляет собой связный неориентированный гpaф древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из упорядоченного набора деревьев.

В рамках иерархической модели выделяют языковые средства описания данных (ЯОД) и средства манипулирования данными (ЯМД). {Каждая|Любая} физическая база описывается набором операторов, обусловливающих как ее логическую структуру, так и структуру хранения БД. {При этом|При всем этом} {способ|метод} доступа устанавливает {способ|метод} организации {взаимосвязи|связи} физических записей.

Определены {следующие|последующие} {способы|методы} доступа:

· иерархически {последовательный|поочередный};

· иерархически индексно-последовательный;

· иерархически прямой;

· иерархически индексно-прямой;

· индексный.

{Помимо|Кроме} задания имени БД и {способа|метода} доступа описания должны содержать определения типов {сегментов|частей}, составляющих БД, в {соответствии|согласовании} с иерархией, начиная с корневого {сегмента|сектора}. {Каждая|Любая} физическая БД содержит {только|лишь} один корневой {сегмент|сектор}, но в системе {может быть|быть может} несколько физических БД.

{Среди|Посреди} операторов манипулирования данными можно выделить операторы поиска данных, операторы поиска данных с возможностью модификации, операторы модификации данных. Набор операций манипулирования данными в иерархической БД невелик, но {вполне|полностью} достаточен.

Иерархической базой данных является
, с которым можно работать, запустив Проводник. Верхний уровень занимает {компьютер|комп}, Мои документы, Сетевое {окружение|свита}
и
, которые являются потомками папки
, а {между|меж} собой является близнецами. В свою очередь, диск 3,5(А:), (С:), (D:), (Е:), (F:)
) и системным папкам (
и др.)

Иерархической базой данных является
, {в котором|в каком} хранится вся информация, {необходимая|нужная} для {нормального|обычного} функционирования компьютерной системы (данные о конфигурации {компьютера|компа} и установленных драйверах, сведения {об|о} установленных {программах|программках}, {настройки|опции} графического интерфейса и др.).

Содержание реестра {автоматически|автоматом} обновляется при установке {нового|новейшего} оборудования, {инсталляции|установки} программ и т. п. Для просмотра и редактирования реестра Windows в ручном режиме можно {использовать|применять|употреблять} специальную {программу|программку} rege-dit.exe, которая хранится в папке Windows. {Однако|Но} редактирование реестра можно проводить {только|лишь} в случае {крайней|последней} необходимости и при условии {понимания|осознания} выполняемых действий. Неквалифицированное редактирование реестра может привести {компьютер|комп} в неработоспособное состояние.

Еще одним примером иерархической базы данных является база данных
{подключенных|присоединенных} к {Интернету|Вебу} {компьютеров|компов}. На верхнем уровне находится табличная база данных, содержащая {перечень|список} доменов верхнего уровня (всего 264 домена), из которых 7 — административные, а {остальные|другие} 257 — географические. {Наиболее|Более} {крупным|большим} доменом (данные на январь 2002 года) является домен net (около 48 миллионов серверов), а в {некоторых|неких} доменах ({например|к примеру}, в домене zr) {до сих пор|до сего времени} не {зарегистрировано|записанно} ни {одного|1-го} сервера.

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

На {третьем|3-ем} уровне могут находиться табличные базы данных, содержащие {перечень|список} доменов третьего уровня для {каждого|всякого} домена второго уровня, и таблицы, содержащие IP-адреса {компьютеров|компов}, находящихся в домене второго уровня.

База данных
{должна|обязана} содержать записи обо всех {компьютерах|компах}, {подключенных|присоединенных} к {Интернету|Вебу}, {то есть|другими словами} {более|наиболее} 150 миллионов записей. Размещение {такой|таковой} {огромной|большой} базы данных на одном {компьютере|компе} сделало бы поиск {информации|инфы} {очень|весьма} {медленным|неспешным} и неэффективным. Решение {этой|данной|данной нам|данной для нас} {проблемы|трудности|задачи|препядствия} было найдено {путем|методом} размещения отдельных составных частей базы данных на {различных|разных} DNS-серверах. {Таким|Таковым} образом, иерархическая база данных
является
.

Поиск {информации|инфы} в {такой|таковой} иерархической распределенной базе данных ведется {следующим|последующим} образом. {например|к примеру}, мы {хотим|желаем} ознакомиться с содержанием WWW-сервера {фирмы|компании|конторы} Microsoft.

{Сначала|Поначалу} наш запрос, содержащий доменное имя сервера www.microsoft..com, будет оправлен на DNS- нашего провайдера, который переадресует его на DNS- самого верхнего уровня базы данных. В таблице первого уровня будет найден интересующий нас домен com и запрос будет адресован на DNS-сервер второго уровня, который содержит {перечень|список} доменов второго уровня, зарегистрированных в домене com.

В таблице второго уровня будет найден домен microsoft и запрос будет переадресован на DNS- третьего уровня. В таблице третьего уровня будет найдена запись, {соответствующая|соответственная} доменному имени, содержавшемуся в запросе. Поиск {информации|инфы} в базе данных
будет завершен и начнется поиск {компьютера|компа} в сети по его IP-адресу.

2. Сетевые БД

Сетевая СУБД
— система управления базами данных, поддерживающая сетевую {организацию|компанию}: {любая|неважно какая} запись, {называемая|именуемая} записью старшего уровня, может содержать данные, которые относятся к набору {других|остальных} записей, {называемых|именуемых} записями подчиненного уровня.

{Типичным|Обычным} представителем является Integrated Database Management System {появилась|возникла} в 70-х годах. Сетевой подход к организации данных является расширением иерархического. Сетевая БД состоит из набора записей и набора связей {между|меж} этими записями. На формирование связи {особых|особенных} ограничений не накладывается. В иерархических структурах запись-потомок {должна|обязана} иметь в точности {одного|1-го} предка; в сетевой структуре данных потомок может иметь {любое|хоть какое} число {предков|протцов}. Достоинством сетевой модели данных является возможность {эффективной|действенной} реализации по показателям {затрат|издержек} памяти и оперативности. В {сравнении|сопоставлении} с иерархической моделью сетевая модель предоставляет {большие|огромные} {возможности|способности} в смысле допустимости образования {произвольных|случайных} связей. В рамках сетевых СУБД {легко|просто} реализуются и иерархические даталогические модели. Сетевые СУБД поддерживают сложные соотношения {между|меж} типами данных, что делает их {пригодными|подходящими} {во многих|в почти всех} {различных|разных} приложениях. {Однако|Но} {пользователи|юзеры} {таких|таковых} СУБД ограничены связями, определенными для {них|их} {разработчиками|разрабами} БД-приложений. {Более|Наиболее} того, подобно иерархическим сетевые СУБД {предполагают|подразумевают} разработку БД приложений {опытными|опытнейшеми} {программистами|программерами} и системными аналитиками.

{Недостатком|Недочетом} сетевой модели данных является {высокая|высочайшая} сложность и {жесткость|твердость} схемы БД, построенной на ее {основе|базе}, {а также|также} сложность для {понимания|осознания} и выполнения обработки {информации|инфы} в БД {обычным|обыденным} {пользователем|юзером}. {Кроме|Не считая} того, в сетевой модели данных ослаблен контроль целостности связей вследствие допустимости установления {произвольных|случайных} связей {между|меж} записями.

Просматривая, {к примеру|например}, в сетевой СУБД записи объекта «Лицо» и выбрав запись «Иванов» (т. е. поместив табличный курсор на {соответствующую|подобающую} запись), можно через активизацию поля «Работает» вызвать на экран поля связанной записи в объекте «Организация» и просмотреть {соответствующие|надлежащие} данные, а {далее|дальше}, {при необходимости|по мере необходимости}, через активизацию поля «{Адрес|Адресок}» в записи по объекту «Организация» вызвать и просмотреть данные по дислокации места работы сотрудника «Иванов» и т. д.

Данный пример {показывает|указывает}, что
{позволяют|разрешают} {пользователю|юзеру} реализовывать свои
(«беседовать» с базой данных) {более|наиболее}
шаг за шагом уточняя свои потребности, и {тем самым|тем} {более|наиболее} глубоко и наглядно {анализировать|рассматривать} ({изучать|учить}) данные.

3. Реляционные БД

К.Дейт в {своей|собственной} {классической|традиционной} {книге|книжке} «Введение в системы баз данных» дает {следующее|последующее} определение реляционной системы управления базами данных:

1. Данные воспринимаются {пользователем|юзером} как таблицы (и никак {иначе|по другому}).

2. В распоряжении {пользователя|юзера} имеются операторы, которые генерируют {новые|новейшие} таблицы из {старых|старенькых}.

одна из {непосредственных|конкретных} задач СУБД ({здесь|тут} и {далее|дальше} речь идет о реляционных СУБД, {поэтому|потому} слово «реляционный» опускается) — {осуществлять|производить} контроль целостности данных. Под целостностью данных {подразумевается|предполагается} логическая непротиворечивость данных. Различают три понятия целостности:

1. Целостность в отношении {конкретной|определенной} базы — такие данные, как возраст, рост, вес не могут быть отрицательными. IP-{адрес|адресок} имеет строго {заданный|данный} формат — это четыре числа в {диапазоне|спектре} от 0 до 255, {разделенных|разбитых} точкой, плюс {дополнительные|доп} ограничения на {использование|внедрение} 0, 255 и спецадресов. {Большинство|Большая часть} СУБД не предоставляют {механизмов|устройств}, {в полной мере|полностью} позволяющих {контролировать|надзирать} данный тип целостности.

2. Целостность сущностей — в таблице, где хранятся записи {об|о} объектах, не {может быть|быть может} {двух|2-ух} {одинаковых|схожих} объектов, {а также|также} не {может быть|быть может} неопределенных объектов, т.е. записей с неопределенным значением (NULL-значением) первичного ключа. СУБД не {должна|обязана} допускать записей с {повторяющимися|циклическими} значениями первичного ключа {или|либо} NULL-значением {одного|1-го} из {компонентов|компонент} первичного ключа. Данный тип целостности поддерживают все СУБД. {Более|Наиболее} {подробно|тщательно} мы {поговорим|побеседуем} {об|о} этом понятии целостности ниже, при описании первичных ключей.

3. Ссылочная целостность — одной записи в таблице гостевых {книг|книжек} может соответствовать несколько записей в таблице сообщений. Таблицы могут находиться во взаимосвязях один к одному, один ко {многим|почти всем} и {многие|почти все} ко {многим|почти всем}. Связи {между|меж} таблицами осуществляются на основании {внешних|наружных} ключей. В таблице сообщений не {может быть|быть может} сообщения, принадлежащего к несуществующей гостевой {книге|книжке}, {иначе|по другому} говоря, {любой|хоть какой} записи в таблице сообщений {должна|обязана} найтись запись в таблице гостевых {книг|книжек}. СУБД {должна|обязана} предоставлять механизмы для контроля операций и соблюдения ссылочной целостности при выполнении операций INSERT, UPDATE и DELETE. К {сожалению|огорчению}, не все СУБД имеют такие механизмы.

{Помимо|Кроме} {невысокой|низкой} эффективности, к {недостаткам|недочетам} {традиционных|обычных} реляционных СУБД можно отнести факт того, что в качестве основного и, {часто|нередко}, единственного механизма, обеспечивающего {быстрый|резвый} поиск и {выборку|подборку} отдельных строк таблице ({или|либо} в связанных через {внешние|наружные} ключи таблицах), обычно {используются|употребляются} {различные|разные} модификации индексов, основанных на B-деревьях. Такое решение оказывается {эффективным|действенным} {только|лишь} при обработке {небольших|маленьких} групп записей и {высокой|высочайшей} интенсивности модификации данных в базах данных.

{Рассмотрим|Разглядим} {более|наиболее} детально все три понятия целостности данных по порядку. К первому типу целостности относятся такие механизмы СУБД, как ограничение на {диапазон|спектр} допустимых значений, триггеры и транзакции. К {сожалению|огорчению}, пока ни один из этих {механизмов|устройств} не поддерживается СУБД MySQL, {поэтому|потому}, если ваши {сайты|веб-сайты} будут базироваться на данной СУБД, то {вам|для вас} придется обождать до {появления|возникновения} данных {возможностей|способностей}. Ограничения на значения должны {появится|покажется} уже в четвертой версии MySQL. {При помощи|С помощью} ограничений на значения можно задать ограничение на формат адреса {электронной|электрической} почты.

email varchar(32) CHECK (email LIKE ‘%@%’),

{Тем самым|Тем}, запретив значения, которые не содержат знака ‘@’. {Большинство|Большая часть} же информационных систем применительно к {веб|интернет}-сайтам, будь то конференции, чаты, списки рассылки, имеют {довольно|достаточно} {простую|ординарную} структуру базы данных, обычно не {превышающую|превосходящую} 5-7 таблиц. В {таких|таковых} системах целостность данных не имеет {критического|критичного} значения. В случае ввода {неправильного|неверного} адреса {электронной|электрической} почты ничего {катастрофического|чертовского} не произойдет, {поэтому|потому} контроль за целостностью данных можно переложить на приложения, т.е. CGI-программы.
Механизм триггеров {позволяет|дозволяет} СУБД {контролировать|надзирать} операции INSERT, UPDATE и DELETE на предмет допустимости этих операций. {например|к примеру}, {таким|таковым} образом, вы {можете|сможете} ограничить число публикуемых сообщений в {день|денек} от {одного|1-го} {пользователя|юзера} {или|либо} запретить вводить сообщения, длиной {более|наиболее} 255 {символов|знаков}, лицам, незаполнившим поля email и http.
И {наконец|в конце концов}, {последний|крайний} механизм транзакций, о котором {вам|для вас} {необходимо|нужно} иметь один из {них|их} не будет выполнен. Транзакции могут применятся при вставке, изменении и удалении данных в нескольких таблицах. {например|к примеру}, {вам|для вас} {необходимо|нужно} в системе гостевых {книг|книжек} {объединить|соединить} две гостевые {книги|книжки} в одну. Для этого {необходимо|нужно} {изменить|поменять} идентификатор гостевой {книги|книжки} gb_id в таблице сообщений, удалить одну запись из таблицы гостевых {книг|книжек} и, {возможно|может быть}, {модифицировать|видоизменять} запись о первой гостевой {книге|книжке}. И мы должны быть {полностью|стопроцентно|на сто процентов|вполне} {уверены|убеждены} в том, что {либо|или} эти операции пройдут {успешно|удачно}, {либо|или} же не будет выполнена ни одна из {них|их}.

{Далее|Дальше} мы {рассмотрим|разглядим} целостность сущностей. Как уже было сказано выше, целостность сущностей базируется на первичном ключе. Мы дадим определение первичного ключа и {рассмотрим|разглядим} ряд примеров таблицы и {методов|способов} выбора первичных ключей.

Первичный ключ
— это столбец {или|либо} группа столбцов в одной таблице {таких|таковых}, что не может существовать {двух|2-ух} записей с {одинаковым|схожим} значением этого столбца {или|либо} группы столбцов, {причем|при этом} для {случая|варианта} группы столбцов никакое подмножество столбцов не является {уникальным|неповторимым}.

Можно выделить {принципиально|принципно} различающиеся три {случая|варианта}:

1. в таблице отсутствует первичный ключ;

2. {простой|обычный|обычной} первичный ключ, т.е. состоящий из {одного|1-го} столбца;

3. составной первичный ключ, т.е. состоящий из нескольких столбцов.

{Рассмотрим|Разглядим} {первый|1-ый} {случай|вариант}, когда в таблице может и не быть первичного ключа, как, {например|к примеру}, в таблице hit в системе анализа {посетителей|гостей} веб-{сайта|веб-сайта}. В {этой|данной|данной нам|данной для нас} таблице просто нет столбцов, которые могли бы образовать первичный ключ. В таблице, чисто {теоретически|на теоретическом уровне}, с {очень|весьма} малой {долей|толикой} вероятности могут быть {полностью|стопроцентно|на сто процентов|вполне} {одинаковые|однообразные|схожие} {строки|строчки}. один {пользователь|юзер} может запустить на {своем|собственном} {компьютере|компе} два броузера и открыть в {них|их} {страницу|страничку} нашего {сайта|веб-сайта}. Из-за того, что ни операционная система, ни протокол TCPIP не работают в {реальном|настоящем} времени, и в {них|их} имеются задержки по времени, есть {вероятность|возможность} того, что открытие в этих броузерах нашей {страницы|странички} произойдет {одновременно|сразу}. Соответственно, {поскольку|так как} броузеры одни и те же, работают на одном {компьютере|компе}, то {программа|программка} counter {внесет|занесет} в таблицу hit две {одинаковые|однообразные|схожие} {строчки|строки}. Также {небольшое|маленькое} пояснение, что CGI-{программа|программка} counter {может быть|быть может} запущена {одновременно|сразу} несколько раз, и что сервер тоже работает не в {реальном|настоящем} времени, {поэтому|потому} и есть {вероятность|возможность} {появления|возникновения} {одинаковых|схожих} строк.
В таблице hit нет необходимости различать записи, т.е. иметь первичный ключ. {Если бы|Если б} {такая|таковая} необходимость была, то можно было бы добавить в таблицу счетчик записей. В СУБД MYSQL это делается {следующим|последующим} образом:

CREATE TABLE hit(

hit_id int(10) unsigned NOT NULL auto_increment,

…

)

При вставке {новой|новейшей} записи hit_id будет {увеличиваться|возрастать} на единицу, {тем самым|тем} мы получим возможность различать записи {внутри|снутри} таблицы. В системе гостевых {книг|книжек} первичными ключами являются поля gb_id в таблице гостевых {книг|книжек} и Message_id в таблице сообщений. На практике {чаще|почаще} всего встречается {именно|конкретно} {такой|таковой} {способ|метод} {назначения|предназначения} и использования первичных ключей. В таблицах системы гостевых {книг|книжек} первичные ключи служат для идентификации записей и установления {отношения|дела} один ко {многим|почти всем}. В {классической|традиционной} теории для соблюдения целостности сущностей {необходимо|нужно} назначать первичным ключом столбец {или|либо} группу столбцов, которые {однозначно|совершенно точно} идентифицируют объект. Но в {реальности|действительности}, {зачастую|часто}, {таких|таковых} столбцов может и не быть. Ни в таблице сообщений, ни в таблице гостевых {книг|книжек} нет осмысленной группы столбцов, которую бы можно было назначить первичным ключом. В данном случае, первичным ключом можно {только|лишь} {сделать|создать} все столбцы таблицы сообщений, но, в этом случае, мы осложняем {себе|для себя} жизнь {при выборе|при выбирании} {конкретного|определенного} сообщения. В запросе SELECT * FROM Message WHERE name=’name’ AND email=’email’ AND… придется перечислить совпадение для {каждого|всякого} столбца. {Такая|Таковая} {выборка|подборка} будет происходить {медленно|медлительно}, т.к. {нужно|необходимо} затратить время, {чтобы|чтоб} выполнить {сравнение|сопоставление} для {каждого|всякого} столбца. {Гораздо|Еще} удобнее ввести счетчик, тогда запрос будет {выглядеть|смотреться} {значительно|существенно} проще: SELECT * FROM Message WHERE id=’id’.
Если же у вас в таблице имеется {все же|все таки} столбец {или|либо} несколько столбцов, {однозначно|совершенно точно} идентифицирующих объект, то их {бесспорно|безусловн} стоит назначить первичным ключом. {например|к примеру}, у вас база данных по {автомобилям|карам}, в этом случае, первичным ключом будет номер {автомобиля|кара}. Не стоит пугаться того, что номер {автомобиля|кара} представляется символьной {строкой|строчкой}. Когда вы назначаете столбец {или|либо} группу столбцов первичным ключом, по ним {автоматически|автоматом} создается индекс. Индекс представляет собой хеш-таблицу, т.е. таблицу из {двух|2-ух} колонок: в первой колонке в отсортированном порядке идут значения первичного ключа, а во {второй|2-ой} колонке — указатель на то {место|пространство}, где лежит полная запись таблицы. {Поскольку|Так как} {первая|1-ая} колонка отсортирована, то операции поиска по {такой|таковой} таблице происходят на порядок {быстрее|резвее}, чем {если бы|если б} индекса не было. Для всех полей таблицы, которые участвуют в предложении WHERE SQL-запросов, {надо|нужно} {обязательно|непременно} создавать индексы. {Однако|Но}, учтите, что индекс ускоряет поиск {только|лишь} в случае, если его значения слабо повторяются. Одним словом, если вы сделаете индекс по полю «пол», то никакого {ускорения|убыстрения} не получится, т.к. половина хеш-таблицы будет состоять из одних записей, а половина из {других|остальных}. В MySQL индекссоздаетсяследующейкомандой:

CREATE [UNIQUE] INDEX index_name ON tablename (column1, column2, …)

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

{Внешний|Наружный} ключ
— это столбец {или|либо} группа столбцов в одной таблице R1, совпадающих по типу данных с первичным ключом в таблице R2, и {каждому|любому} значению этого столбца {или|либо} группы столбцов в таблице R1 {обязательно|непременно} {должно|обязано} найтись совпадающее с ним

{Далее|Дальше} мы {рассмотрим|разглядим} типы отношений {между|меж} таблицами:

Отношение один ко {многим|почти всем}
Отношение {многие|почти все} ко {многим|почти всем}
Отношение один к одному

Отношение один ко {многим|почти всем} мы уже детально {рассмотрели|разглядели} на примере системы гостевых {книг|книжек}. Данного типа {отношения|дела} реализуются {при помощи|с помощью} {внешнего|наружного} ключа в одной таблице, который ссылается на первичный ключ {другой|иной} таблицы.
{Рассмотрим|Разглядим} пример базы данных системы конференций. На конференцию {авторами|создателями} докладов подаются статьи. У каждой статьи {может быть|быть может} несколько {авторов|создателей}. У {каждого|всякого} {автора|создателя} {может быть|быть может} несколько статей. Подобного рода {отношения|дела} {называются|именуются} {многие|почти все} ко {многим|почти всем} и реализуются {при помощи|с помощью} {дополнительной|доборной} таблицы с {двумя|2-мя} {внешними|наружными} ключами, которые образуют первичный ключ.

Мы {видим|лицезреем} таблицу {авторов|создателей}, которая относится к таблице aa (сокращение от authorarticle), как один ко {многим|почти всем}. Это {означает|значит}, что для одной записи в таблице {авторов|создателей} {может быть|быть может} несколько записей в таблице aa. Аналогичным образом и таблица статей относится к таблице aa, как один ко {многим|почти всем}. А {между|меж} таблицами {авторов|создателей} и статей реализуется отношение {многие|почти все} ко {многим|почти всем}.

4. Объектно-ориентированные БД

В {наиболее|более} общей и {классической|традиционной} постановке объектно-ориентированный подход базируется на концепциях:

1. объекта и идентификатора объекта;

2. атрибутов и {методов|способов};

3. классов;

4. иерархии и наследования классов.

{Непосредственным|Конкретным} предшественником объектно-ориентированных СУБД являются системы, поддерживающие {организацию|компанию} сложных объектов. Эти постреляционные системы большей частью {появились|возникли} {по причине|из-за} несоответствия {возможностей|способностей} реляционных СУБД потребностям {нетрадиционных|нестандартных} приложений (автоматизация проектирования, инженерия и т.д.). {По сути|На самом деле} дела, в {таких|таковых} системах {частично|отчасти} поддерживается структурная часть ООБД (без {возможностей|способностей} наследования). {Многие|Почти все} объектно-ориентированные СУБД ({в частности|а именно}, ORION) разрабатывались на базе {предыдущих|прошлых} работ со сложными объектами.

{другой|иной} основой объектно-ориентированных СУБД являются так {называемые|именуемые} расширяемые системы. Основная {идея|мысль} {таких|таковых} систем состоит в поддержании набора модулей с {четко|верно} {оговоренными|обсужденными} интерфейсами, на базе которого можно {быстро|стремительно} {построить|выстроить} СУБД, опирающуюся на {конкретную|определенную} модель данных {или|либо} {предназначенную для|созданную для} {конкретной|определенной} области применений. {В частности|А именно}, как {показывает|указывает} опыт системы EXODUS, средства расширяемых систем {хорошо|отлично} {пригодны|подходящи} и для построения объектно-ориентированной СУБД.

{Наибольшую|Самую большую} {функциональную|многофункциональную} нагрузку несет компонент управления объектами. В число функций {этой|данной|данной нам|данной для нас} подсистемы {входит|заходит}:

— управление сложными объектами, включая создание и {уничтожение|ликвидирование} объектов, {выборку|подборку} объектов по именам, поддержку предопределенных {методов|способов}, поддержку объектов со внутренней структурой-множеством, {списком|перечнем} и кортежем;

— управление передачей сообщений {между|меж} объектами;

— управление транзакциями;

— управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

— отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во {внешней|наружной} памяти до {тех пор|того времени}, пока достижим из {какого-либо|какого-нибудь} долговременно хранимого объекта);

— управление буферами {оперативной памяти|оперативки} (аналогично ORION, систематизация СУБД:

· иерархические

· сетевые

· реляционные

· объектно-ориентированные

1. Иерархические БД

Определены последующие методы доступа:

· иерархически поочередный;

· иерархически индексно-последовательный;

· иерархически прямой;

· иерархически индексно-прямой;

· индексный.

2. Сетевые БД

3. Реляционные БД

1. Данные воспринимаются юзером как таблицы (и никак по другому).

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

email varchar(32) CHECK (email LIKE ‘%@%’),

Можно выделить принципно различающиеся три варианта:

1. в таблице отсутствует первичный ключ;

2. обычный первичный ключ, т.е. состоящий из 1-го столбца;

3. составной первичный ключ, т.е. состоящий из нескольких столбцов.

Разглядим 1-ый вариант, когда в таблице может и не быть первичного ключа, как, к примеру, в таблице hit в системе анализа гостей веб-веб-сайта. В данной нам таблице просто нет столбцов, которые могли бы образовать первичный ключ. В таблице, чисто на теоретическом уровне, с весьма малой толикой вероятности могут быть вполне схожие строчки. один юзер может запустить на собственном компе два броузера и открыть в их страничку нашего веб-сайта. Из-за того, что ни операционная система, ни протокол TCPIP не работают в настоящем времени, и в их имеются задержки по времени, есть возможность того, что открытие в этих броузерах нашей странички произойдет сразу. Соответственно, так как броузеры одни и те же, работают на одном компе, то программка counter занесет в таблицу hit две схожие строки. Также маленькое пояснение, что CGI-программка counter быть может запущена сразу несколько раз, и что сервер тоже работает не в настоящем времени, потому и есть возможность возникновения схожих строк.
В таблице hit нет необходимости различать записи, т.е. иметь первичный ключ. Если б таковая необходимость была, то можно было бы добавить в таблицу счетчик записей. В СУБД MYSQL это делается последующим образом:

CREATE TABLE hit(

hit_id int(10) unsigned NOT NULL auto_increment,

…

)

CREATE [UNIQUE] INDEX index_name ON tablename (column1, column2, …)

Дальше мы разглядим типы отношений меж таблицами:

Отношение один ко почти всем
Отношение почти все ко почти всем
Отношение один к одному

4. Объектно-ориентированные БД

В более общей и традиционной постановке объектно-ориентированный подход базируется на концепциях:

1. объекта и идентификатора объекта;

2. атрибутов и способов;

3. классов;

4. иерархии и наследования классов.

— управление передачей сообщений меж объектами;

— управление транзакциями;

— управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

— управление буферами оперативки (аналогично ORION, созданная для сотворения, введения и использования баз данных.

систематизация СУБД:

· иерархические

· сетевые

· реляционные

· объектно-ориентированные

1. Иерархические БД

Определены последующие методы доступа:

· иерархически поочередный;

· иерархически индексно-последовательный;

· иерархически прямой;

· иерархически индексно-прямой;

· индексный.

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

2. Сетевые БД

3. Реляционные БД

1. Данные воспринимаются юзером как таблицы (и никак по другому).

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

email varchar(32) CHECK (email LIKE ‘%@%’),

Тем, запретив значения, которые не содержат знака ‘@’. Большая часть же информационных систем применительно к интернет-сайтам, будь то конференции, чаты, списки рассылки, имеют достаточно ординарную структуру базы данных, обычно не превосходящую 5-7 таблиц. В таковых системах целостность данных не имеет критичного значения. В случае ввода неверного адреса электрической почты ничего чертовского не произойдет, потому контроль за целостностью данных можно переложить на приложения, т.е. CGI-программы.
Механизм триггеров дозволяет СУБД надзирать операции INSERT, UPDATE и DELETE на предмет допустимости этих операций. к примеру, таковым образом, вы сможете ограничить число публикуемых сообщений в денек от 1-го юзера либо запретить вводить сообщения, длиной наиболее 255 знаков, лицам, незаполнившим поля email и http.
И в конце концов, крайний механизм транзакций, о котором для вас нужно иметь обычно наименее ярки и наименее детальны чем образы восприятия но в их находит отражение самое свойственное для данного предмета Различия в яркости стойкости и точности представлений памяти весьма инди, дозволяет надзирать выполнение блоков SQL-запросов. Транзакция представляет собой набор SQL-запросов, и СУБД гарантирует, что или все эти запросы будут выполнены, или же ни один из их не будет выполнен. Транзакции могут применятся при вставке, изменении и удалении данных в нескольких таблицах. к примеру, для вас нужно в системе гостевых книжек соединить две гостевые книжки в одну. Для этого нужно поменять идентификатор гостевой книжки gb_id в таблице сообщений, удалить одну запись из таблицы гостевых книжек и, может быть, видоизменять запись о первой гостевой книжке. И мы должны быть вполне убеждены в том, что или эти операции пройдут удачно, или же не будет выполнена ни одна из их.

Можно выделить принципно различающиеся три варианта:

1. в таблице отсутствует первичный ключ;

2. обычный первичный ключ, т.е. состоящий из 1-го столбца;

3. составной первичный ключ, т.е. состоящий из нескольких столбцов.

CREATE TABLE hit(

hit_id int(10) unsigned NOT NULL auto_increment,

…

)

CREATE [UNIQUE] INDEX index_name ON tablename (column1, column2, …)

Наружный ключ
—

Дальше мы разглядим типы отношений меж таблицами:

Отношение один ко почти всем
Отношение почти все ко почти всем
Отношение один к одному

4. Объектно-ориентированные БД

В более общей и традиционной постановке объектно-ориентированный подход базируется на концепциях:

1. объекта и идентификатора объекта;

2. атрибутов и способов;

3. классов;

4. иерархии и наследования классов.

— управление передачей сообщений меж объектами;

— управление транзакциями;

— управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

— управление буферами оперативки (аналогично ORION, обычно наименее ярки и наименее детальны чем образы восприятия но в их находит отражение самое свойственное для данного предмета Различия в яркости стойкости и точности представлений памяти весьма инди объекта в оперативки различается от его представления на диске);

— управление кластеризацией объектов во наружной памяти;

— управление индексами.

]]>

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

классификация СУБД:

· иерархические

· сетевые

· реляционные

· объектно-ориентированные

1. Иерархические БД

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

Основными информационными единицами в иерархической модели данных являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Для сегмента определяются тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений полей данных. Тип сегмента — это поименованная совокупность входящих в него типов полей данных. Как и сетевая, иерархическая модель данных базируется на графовой форме построения данных, и на концептуальном уровне она является просто частным случаем сетевой модели данных. В иерархической модели данных вершине графа соответствует тип сегмента или просто сегмент, а дугам — типы связей предок — потомок. В иерархических структуpax сегмент — потомок должен иметь в точности одного предка. Иерархическая модель представляет собой связный неориентированный гpaф древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из упорядоченного набора деревьев.

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

Определены следующие способы доступа:

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

· иерархически индексно-последовательный;

· иерархически прямой;

· иерархически индексно-прямой;

· индексный.

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

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

Иерархической базой данных является
, с которым можно работать, запустив Проводник. Верхний уровень занимает компьютер, Мои документы, Сетевое окружение
и
, которые являются потомками папки
, а между собой является близнецами. В свою очередь, диск 3,5(А:), (С:), (D:), (Е:), (F:)
) и системным папкам (
и др.)

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

Содержание реестра автоматически обновляется при установке нового оборудования, инсталляции программ и т. п. Для просмотра и редактирования реестра Windows в ручном режиме можно использовать специальную программу rege-dit.exe, которая хранится в папке Windows. Однако редактирование реестра можно проводить только в случае крайней необходимости и при условии понимания выполняемых действий. Неквалифицированное редактирование реестра может привести компьютер в неработоспособное состояние.

Еще одним примером иерархической базы данных является база данных
подключенных к Интернету компьютеров. На верхнем уровне находится табличная база данных, содержащая перечень доменов верхнего уровня (всего 264 домена), из которых 7 — административные, а остальные 257 — географические. Наиболее крупным доменом (данные на январь 2002 года) является домен net (около 48 миллионов серверов), а в некоторых доменах (например, в домене zr) до сих пор не зарегистрировано ни одного сервера.

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

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

База данных
должна содержать записи обо всех компьютерах, подключенных к Интернету, то есть более 150 миллионов записей. Размещение такой огромной базы данных на одном компьютере сделало бы поиск информации очень медленным и неэффективным. Решение этой проблемы было найдено путем размещения отдельных составных частей базы данных на различных DNS-серверах. Таким образом, иерархическая база данных
является
.

Поиск информации в такой иерархической распределенной базе данных ведется следующим образом. например, мы хотим ознакомиться с содержанием WWW-сервера фирмы Microsoft.

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

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

2. Сетевые БД

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

Типичным представителем является Integrated Database Management System появилась в 70-х годах. Сетевой подход к организации данных является расширением иерархического. Сетевая БД состоит из набора записей и набора связей между этими записями. На формирование связи особых ограничений не накладывается. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков. Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с иерархической моделью сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей. В рамках сетевых СУБД легко реализуются и иерархические даталогические модели. Сетевые СУБД поддерживают сложные соотношения между типами данных, что делает их пригодными во многих различных приложениях. Однако пользователи таких СУБД ограничены связями, определенными для них разработчиками БД-приложений. Более того, подобно иерархическим сетевые СУБД предполагают разработку БД приложений опытными программистами и системными аналитиками.

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

Просматривая, к примеру, в сетевой СУБД записи объекта «Лицо» и выбрав запись «Иванов» (т. е. поместив табличный курсор на соответствующую запись), можно через активизацию поля «Работает» вызвать на экран поля связанной записи в объекте «Организация» и просмотреть соответствующие данные, а далее, при необходимости, через активизацию поля «Адрес» в записи по объекту «Организация» вызвать и просмотреть данные по дислокации места работы сотрудника «Иванов» и т. д.

Данный пример показывает, что
позволяют пользователю реализовывать свои
(«беседовать» с базой данных) более
шаг за шагом уточняя свои потребности, и тем самым более глубоко и наглядно анализировать (изучать) данные.

3. Реляционные БД

К.Дейт в своей классической книге «Введение в системы баз данных» дает следующее определение реляционной системы управления базами данных:

1. Данные воспринимаются пользователем как таблицы (и никак иначе).

2. В распоряжении пользователя имеются операторы, которые генерируют новые таблицы из старых.

одна из непосредственных задач СУБД (здесь и далее речь идет о реляционных СУБД, поэтому слово «реляционный» опускается) — осуществлять контроль целостности данных. Под целостностью данных подразумевается логическая непротиворечивость данных. Различают три понятия целостности:

1. Целостность в отношении конкретной базы — такие данные, как возраст, рост, вес не могут быть отрицательными. IP-адрес имеет строго заданный формат — это четыре числа в диапазоне от 0 до 255, разделенных точкой, плюс дополнительные ограничения на использование 0, 255 и спецадресов. Большинство СУБД не предоставляют механизмов, в полной мере позволяющих контролировать данный тип целостности.

2. Целостность сущностей — в таблице, где хранятся записи об объектах, не может быть двух одинаковых объектов, а также не может быть неопределенных объектов, т.е. записей с неопределенным значением (NULL-значением) первичного ключа. СУБД не должна допускать записей с повторяющимися значениями первичного ключа или NULL-значением одного из компонентов первичного ключа. Данный тип целостности поддерживают все СУБД. Более подробно мы поговорим об этом понятии целостности ниже, при описании первичных ключей.

3. Ссылочная целостность — одной записи в таблице гостевых книг может соответствовать несколько записей в таблице сообщений. Таблицы могут находиться во взаимосвязях один к одному, один ко многим и многие ко многим. Связи между таблицами осуществляются на основании внешних ключей. В таблице сообщений не может быть сообщения, принадлежащего к несуществующей гостевой книге, иначе говоря, любой записи в таблице сообщений должна найтись запись в таблице гостевых книг. СУБД должна предоставлять механизмы для контроля операций и соблюдения ссылочной целостности при выполнении операций INSERT, UPDATE и DELETE. К сожалению, не все СУБД имеют такие механизмы.

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

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

email varchar(32) CHECK (email LIKE ‘%@%’),

Тем самым, запретив значения, которые не содержат знака ‘@’. Большинство же информационных систем применительно к веб-сайтам, будь то конференции, чаты, списки рассылки, имеют довольно простую структуру базы данных, обычно не превышающую 5-7 таблиц. В таких системах целостность данных не имеет критического значения. В случае ввода неправильного адреса электронной почты ничего катастрофического не произойдет, поэтому контроль за целостностью данных можно переложить на приложения, т.е. CGI-программы.
Механизм триггеров позволяет СУБД контролировать операции INSERT, UPDATE и DELETE на предмет допустимости этих операций. например, таким образом, вы можете ограничить число публикуемых сообщений в день от одного пользователя или запретить вводить сообщения, длиной более 255 символов, лицам, незаполнившим поля email и http.
И наконец, последний механизм транзакций, о котором вам необходимо иметь один из них не будет выполнен. Транзакции могут применятся при вставке, изменении и удалении данных в нескольких таблицах. например, вам необходимо в системе гостевых книг объединить две гостевые книги в одну. Для этого необходимо изменить идентификатор гостевой книги gb_id в таблице сообщений, удалить одну запись из таблицы гостевых книг и, возможно, модифицировать запись о первой гостевой книге. И мы должны быть полностью уверены в том, что либо эти операции пройдут успешно, либо же не будет выполнена ни одна из них.

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

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

Можно выделить принципиально различающиеся три случая:

1. в таблице отсутствует первичный ключ;

2. простой первичный ключ, т.е. состоящий из одного столбца;

3. составной первичный ключ, т.е. состоящий из нескольких столбцов.

Рассмотрим первый случай, когда в таблице может и не быть первичного ключа, как, например, в таблице hit в системе анализа посетителей веб-сайта. В этой таблице просто нет столбцов, которые могли бы образовать первичный ключ. В таблице, чисто теоретически, с очень малой долей вероятности могут быть полностью одинаковые строки. один пользователь может запустить на своем компьютере два броузера и открыть в них страницу нашего сайта. Из-за того, что ни операционная система, ни протокол TCPIP не работают в реальном времени, и в них имеются задержки по времени, есть вероятность того, что открытие в этих броузерах нашей страницы произойдет одновременно. Соответственно, поскольку броузеры одни и те же, работают на одном компьютере, то программа counter внесет в таблицу hit две одинаковые строчки. Также небольшое пояснение, что CGI-программа counter может быть запущена одновременно несколько раз, и что сервер тоже работает не в реальном времени, поэтому и есть вероятность появления одинаковых строк.
В таблице hit нет необходимости различать записи, т.е. иметь первичный ключ. Если бы такая необходимость была, то можно было бы добавить в таблицу счетчик записей. В СУБД MYSQL это делается следующим образом:

CREATE TABLE hit(

hit_id int(10) unsigned NOT NULL auto_increment,

…

)

При вставке новой записи hit_id будет увеличиваться на единицу, тем самым мы получим возможность различать записи внутри таблицы. В системе гостевых книг первичными ключами являются поля gb_id в таблице гостевых книг и Message_id в таблице сообщений. На практике чаще всего встречается именно такой способ назначения и использования первичных ключей. В таблицах системы гостевых книг первичные ключи служат для идентификации записей и установления отношения один ко многим. В классической теории для соблюдения целостности сущностей необходимо назначать первичным ключом столбец или группу столбцов, которые однозначно идентифицируют объект. Но в реальности, зачастую, таких столбцов может и не быть. Ни в таблице сообщений, ни в таблице гостевых книг нет осмысленной группы столбцов, которую бы можно было назначить первичным ключом. В данном случае, первичным ключом можно только сделать все столбцы таблицы сообщений, но, в этом случае, мы осложняем себе жизнь при выборе конкретного сообщения. В запросе SELECT * FROM Message WHERE name=’name’ AND email=’email’ AND… придется перечислить совпадение для каждого столбца. Такая выборка будет происходить медленно, т.к. нужно затратить время, чтобы выполнить сравнение для каждого столбца. Гораздо удобнее ввести счетчик, тогда запрос будет выглядеть значительно проще: SELECT * FROM Message WHERE id=’id’.
Если же у вас в таблице имеется все же столбец или несколько столбцов, однозначно идентифицирующих объект, то их бесспорно стоит назначить первичным ключом. например, у вас база данных по автомобилям, в этом случае, первичным ключом будет номер автомобиля. Не стоит пугаться того, что номер автомобиля представляется символьной строкой. Когда вы назначаете столбец или группу столбцов первичным ключом, по ним автоматически создается индекс. Индекс представляет собой хеш-таблицу, т.е. таблицу из двух колонок: в первой колонке в отсортированном порядке идут значения первичного ключа, а во второй колонке — указатель на то место, где лежит полная запись таблицы. Поскольку первая колонка отсортирована, то операции поиска по такой таблице происходят на порядок быстрее, чем если бы индекса не было. Для всех полей таблицы, которые участвуют в предложении WHERE SQL-запросов, надо обязательно создавать индексы. Однако, учтите, что индекс ускоряет поиск только в случае, если его значения слабо повторяются. Одним словом, если вы сделаете индекс по полю «пол», то никакого ускорения не получится, т.к. половина хеш-таблицы будет состоять из одних записей, а половина из других. В MySQL индекссоздаетсяследующейкомандой:

CREATE [UNIQUE] INDEX index_name ON tablename (column1, column2, …)

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

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

Далее мы рассмотрим типы отношений между таблицами:

Отношение один ко многим
Отношение многие ко многим
Отношение один к одному

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

Мы видим таблицу авторов, которая относится к таблице aa (сокращение от authorarticle), как один ко многим. Это означает, что для одной записи в таблице авторов может быть несколько записей в таблице aa. Аналогичным образом и таблица статей относится к таблице aa, как один ко многим. А между таблицами авторов и статей реализуется отношение многие ко многим.

4. Объектно-ориентированные БД

В наиболее общей и классической постановке объектно-ориентированный подход базируется на концепциях:

1. объекта и идентификатора объекта;

2. атрибутов и методов;

3. классов;

4. иерархии и наследования классов.

Непосредственным предшественником объектно-ориентированных СУБД являются системы, поддерживающие организацию сложных объектов. Эти постреляционные системы большей частью появились по причине несоответствия возможностей реляционных СУБД потребностям нетрадиционных приложений (автоматизация проектирования, инженерия и т.д.). По сути дела, в таких системах частично поддерживается структурная часть ООБД (без возможностей наследования). Многие объектно-ориентированные СУБД (в частности, ORION) разрабатывались на базе предыдущих работ со сложными объектами.

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

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

— управление сложными объектами, включая создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем;

— управление передачей сообщений между объектами;

— управление транзакциями;

— управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

— отслеживание долговременно хранимых объектов (напомним, что в O2 объект хранится во внешней памяти до тех пор, пока достижим из какого-либо долговременно хранимого объекта);

— управление буферами оперативной памяти (аналогично ORION, http://wpgrabbestrefedu.loc/2019/02/11/utchebnaya-rabota-laboratornaya-rabota-sozdanie-i-obrabotka-baz-dannh-v-subd-access/

Создание и обработка баз данных в СУБД
Access

Общие сведения

база данных
– это организованная структура, созданная для хранения данных и инфы. Система управления базой данных
(СУБД) – это комплекс программных средств, созданных для сотворения структуры новейшей базы, заполнения ее содержимым, редактирования содержимого и визуализации инфы.

Объекты
MS
Access

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

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

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

отчеты
– объект, предназначенный лишь для вывода данных на печатающее устройство.

Странички
– особый объект базы данных, выполненный в коде HTML, размещаемый на Web-странице, осуществляющий интерфейс меж клиентом, сервером и базой данных, размещенной на сервере.

Макросы и модули
– эти группы объектов, созданные для автоматизации циклических операций при работе с СУБД, также для сотворения новейших функций методом программирования на языке VisualBasic.

Эти объекты хранятся в одном файле с расширением (.mdb).
Постановка задачки

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

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

· Списки студентов групп;

· Список изучаемых предметов;

· Преподавательский состав кафедр, обеспечивающих учебный процесс;

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

· Результаты сдачи экзаменов (зачетов) по любому из проведенных занятий.

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

Опосля пуска MicrosoftAccess сразу с его окном выводится 1-ое диалоговое окно, позволяющее начать создание базы данных либо открыть существующую базу данных.

Это окно возникает, если в окне Сервис
|Характеристики|Вид|Показывать
установлен флаг Окно пуска
.

Упражнение 1

метод сотворения файла для новейшей базы данных:

1. В диалоговом окне изберите переключатель Новенькая база данных
—
Сделать

5. Сохранить как
новое имя базы данных

.

Оставьте в поле Тип файла
база данных
Microsoft
Access
— (*.
mdb
)
.

Создание таблицы базы данных

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

Создание структуры таблицы

Access предоставляет несколько методов сотворения таблицы:

· Режим таблицы
— создание таблицы в Режиме таблицы
;

· Конструктор
— создание таблицы при помощи Конструктора
таблиц
;

· Мастер таблиц
— создание таблицы при помощи Мастера таблиц
;

· Импорт таблиц
— создание таблицы методом импортирования данных из наружного файла либо иной базы данных;

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

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

Начните создание таблицы

с определения ее структуры в режиме Конструктора
таблиц.

1. В окне Новенькая таблица
изберите строчку Конструктор
.

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

Описание параметров полей таблицы

имя поля

Тип

данных

Ключевое поле
Размер, б
Число десятичных символов
Подпись
Условие на б
Кол. ст. в группе
>=0 AND <=35
нет
нет

Кол.студентов больше допуст.

пбалл
числовой
с плавающей точкой (4 б)
2
Прох.балл

>2 AND <5 OR 0

_______________

Ошибка в оценке

нет
нет

формат: Фиксиров

2. Если структура таблицы была сотворена либо изменена, ее нужно сохранить. Для сохранения структуры:

· Нажмите клавишу Сохранить
на панели инструментов либо изберите команду Файл|Сохранить

· В показавшемся диалоговом окне введите имя таблицы (может состоять из 64 знаков, не считая точки, восклицательного знака, квадратных скобок, кавычек и пробела сначала, надстрочного знака)

· Если новенькая таблица не имеет главного поля, для автоматического сотворения счетчика ключа нажмите Да
. В нашем примере поле
является главным.

· Закройте таблицу

2. Шаг:

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

Введите записи в таблицы в согласовании с их полями.

Данные таблицы

ном.группы
кол.ст. в группе
проходной балл

101
30
4,50

102
32
4,50

103
29
4,80

104
25
4,40

105
24
4,20

201
25
3,90

202
24
4,00

203
23
3,90

204
24
4,70

205
24
4,20

установка первичного ключа

Для определения первичного ключа выделите поле
и нажмите на панели конструктора таблиц клавишу с изображением ключа либо изберите команду Ключевое поле
из меню Правка
. В MicrosoftAccess можно выделить три типа главных полей:

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

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

Обычный

ключ определяется полем, содержащим неповторимое

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

В вариантах, когда нереально гарантировать неповторимость значений всякого поля, делают составной

ключ, состоящий из нескольких полей. Таковая ситуация возникает для таблицы, применяемой для связывания 2-ух таблиц в отношении «многие-ко-многим».

В нашем примере при определении структуры таблицы

в Режиме конструктора
выделите поля
и
, щелкая клавишей мыши на области маркировки поля при нажатой кнопочке Ctrl
. Потом нажмите клавишу панели инструментов Ключевое поле.

Сохранение данных

В MicrosoftAccessизменения сохраняются автоматом при последующих действиях:

· Переход к последующей записи

· Закрытие режима таблицы либо формы

Добавление и удаление записей

Для прибавления данных в новейшую запись:

1. Перейдите на пустое поле новейшей записи

2. Введите новейшую группу с количеством студентов и проходным баллом, нажимая Tab
либоEnter
для перехода к последующему полю

Для удаления записей:

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

2. Нажмите Del
либо изберите команду Правка|Удалить
записи

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

· Введите в ключевое поле
недозволено ввести запись с циклическим значением ключа. Отмените ввод неправильных значений в поля нажатием Esc
либо командой Правка| Вернуть текущее поле либо запись
.

· Удостоверьтесь, что ключевое поле недозволено бросить пустым

· Введите в поле
Сообщение о ошибке.

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

Метод импортирования таблиц из иной базы данных

1.
Файл|Наружные данные|Импорт

2. В окне Импорт
найдите папку Мои документы
и в ней отметьте файл

3.
Нажмите Импорт
, в открывшемся окне Импорт объектов
нажмите Выделить все|
Ok
.

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

Вставка в запись рисунка либо объекта

Набросок либо объект добавляется из имеющегося файла или создается в приложении OLE (к примеру, в MSPaint), а потом вставляется в текущую запись.

Разглядим размещение объекта OLE на примере поля фото заведующего
в таблице

. Фото хранятся в формате графического редактора Paint в файлах с расширением .bmp.

1. В окне базы данных установите курсор на таблице

и нажмите клавишу Открыть

2. Заполните строчки (записи) открывшейся таблицы данными в согласовании с наименованиями столбцов (полей)

3. Для размещения поля
сделайте внедрение объекта OLE в файл базы данных. Установите курсор в соответственное поле таблицы. Сделайте команду меню Вставка|Объект

4. В окне Вставка объекта
изберите тип объекта PaintbrushPicture и установите флаг Сделать из файла

5. В этом окне можно ввести имя файла, содержащего фотографию.

6. Для просмотра внедренного объекта установите курсор в соответственное поле и два раза щелкните клавишей мыши

7. Чтоб возвратиться из программки Paint, сделайте команду Файл|Выход
и возврат к таблице

.

Размещение данных типа МЕМО в таблице

В таблице

предвидено поле
, которое будет содержать длиннющий текст – короткую программку курса. Для такового поля изберите тип данных Поле
МЕМО

Откройте таблицу

. Сделайте ввод данных в поле
конкретно в таблице или через область ввода, вызываемую нажатием Shift
+
F
2
.

Связывание таблиц

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

установление связи меж таблицами может быть лишь при последующих критериях:

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

· Обе таблицы сохраняются в одной базе данных Access.

От полей, обозначенных при определении связи, зависит тип создаваемой связи:

1. Отношение «один-к-одному» создается в том случае, когда оба связываемых поля являются главными

2. Отношение «один-ко-многим» создается в том случае, когда лишь одно из полей является главным. При таком отношении главной таблицей является таблица, которая содержит первичный ключ и составляет часть «один» тут. Таблица со стороны «много» является подчиненной таблицей. Связывающее поле в ней с таковым же типом инфы, как в первичном ключе главной таблицы, является полем наружного ключа.

3. Связь с отношением «многие-ко-многим» практически представляет две связи с отношением «один-ко-многим» через третью таблицу, ключ которой состоит из 2-ух и наиболее полей, которые являются полями наружного ключа в 2-ух остальных таблицах.

Если для некий из таблиц не было определено ключевое поле, то в поле Тип
дела
отображается текст «Не определено».

1. Откройте окно Схема данных,
нажав клавишу на панели инструментов

2. В диалоговом окне Добавление таблицы
изберите вкладку Таблицы
и, нажимая клавишу Добавить
, разместите в окне Схема данных
все ранее сделанные таблицы базы данных, перечень которых будет отображен в диалоговом окне. Можно добавить все таблицы сходу, выделив 1-ую таблицу и нажав Shift — последнюю таблицу.

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

со перечнями собственных полей.

4. Установите связь меж таблицами

и

по обычному ключу
. Для этого в окне Схема данных
установите курсор мыши на ключевое поле
главной таблицы

и перетащите это поле на поле
в подчиненной таблице

Для удаления неверной связи в окне Схема данных
выделите ненадобную связь и нажмите
Del

.

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

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

7. Установите связи по обычному ключу для остальных пар таблиц:

(ключ

(ключ
,

(ключ
),

(ключ
).

8. Установите связь по составному ключу
+
меж таблицами

. Для этого в главной таблице

выделите оба этих поля, удерживая кнопку Ctrl, и перетащите оба поля на поле
в подчиненной таблице

.

9. В окне Изменение связи
для поля
и НГ таблицы

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

Аналогично по составному ключу
установите связи меж парой таблиц

Ввод и корректировка данных во взаимосвязанных таблицах

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

Если установлен флаг Обеспечение целостности данных,
то Access разрешает юзеру:

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

· Добавить запись в подчиненную таблицу, когда в главной имеется запись с вводимым значением ключа связи;

· Удалить запись в таблице, если нет связанных с ней записей в подчиненных таблицах.

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

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

В Access 2000 имеется возможность во время просмотра таблицы показывать записи подчиненных таблиц. Потому юзер может надзирать правильность связей.

1. Откройте таблицу

2. Если таблица

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

3. Откройте таблицу

и сделайте команду Вставка|Подтаблица

Изберите в окне Вставка подтаблицы
подчиненную таблицу

. В строчках Подчиненные поля и Главные поля
отобразится составной ключ связи

5. Для удаления связи, зафиксированной в свойствах таблицы, откройте таблицу в Режиме таблицы
и сделайте команду меню Формат|Подтаблица|Удалить.

6. Перейдите в Режим конструктора
и нажмите на панели инструментов клавишу характеристики
(либо в контекстном меню) и удостоверьтесь, что в качестве значения характеристики Имя
подтаблицы
установлено Нет
, т.е. связь удалена. Для предстоящей работы восстановите связь.

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

, подчиненные записи таблицы

и в ней подчиненные записи таблицы

.

Для этого поочередно в свойствах таблицы

в строке имя подтаблицы
укажите Таблица

, потом открыв в Режиме конструктора
таблицу

, укажите в свойствах таблицы

.

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

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

. При всем этом НГ+ КП+ ТАБН+ ВИДЗ
вводится в поле подчиненной записи автоматом. Таковым образом, для сотворения подчиненной записи довольно ввести лишь часть ключа
и полученную оценку.

Чтоб узреть из таблицы

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

.

Разработка форм

Вводить информацию в Access можно 2-мя методами: в таблицу и в форму.

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

Неважно какая форма строится на базе Access-таблицы либо запроса. Имена полей извлекаются из спецификации таблицы, а поля в форме можно расположить по собственному усмотрению. На базе одной таблицы юзер может выстроить несколько форм: одну — для деканата, другую — для отдела стратегии, третью- для студентов и т.д.

Форму можно сделать 3-мя методами:

· При помощи конструктора форм;

· При помощи мастера форм
;

· Используя автоформу

Каждую Access-форму можно представить на дисплее в одном из 3-х режимов:

· В режиме конструктора

· В режиме формы
(рабочем режиме)

· В режиме таблицы

Переключение меж режимами осуществляется при помощи команды Вид
.

1. В окне базы данных

изберите объект Формы
и нажмите клавишу Сделать
.

2. В окне новенькая форма изберите в качестве источника данных таблицу

и режим сотворения – Автоформа: в столбец
. Обратите внимание, что подписи полей в форме
соответствуют данным их свойствам при определении структуры таблицы.

3. При сохранении формы Access спросит о имени формы. Можно бросить по дефлоту

, который соответствует имени таблицы- источника.

Конструирование формы

Для конструирования форм в Access употребляется Конструктор форм.
Форма в этом режиме имеет 3 области:

· Область данных

· Заголовок формы

· Примечание формы
,

которые могут быть образованы по команде Вид/Заголовок/Примечание формы
.

Редактирование формы в Режиме конструктора

Разглядите технику редактирования на примере ранее сделанной формы

1. Откройте форму

2. Перейдите в Режим конструктора

3. Для ввода текста заголовка расширьте область заголовка формы.

4. Сделайте графический элемент Надпись
, перетащив клавишу Надпись
с панели частей на поле заголовок форм,
если их нет на дисплее, то включите через меню Вид

5.
Введем в рамку сделанного элемента текст заголовка
.

6. При выделенном элементе откройте диалоговое окно параметров из контекстного меню и изберите вкладку Макет
и установите шрифт ArialCyr
12,
сглаживание по центру, курсивом. Оформление — приподнятое
.

7. Окончите создание элементанажатием Enterили щелчком вне рамки.

8. Введите в область заголовка еще одну надпись: Казахский экономический институт им. Т.Рыскулова
.

9. Для сохранения формы под новеньким именованием

нужно выполнить команду Файл/Сохранить

10. Перейдя в режим формы
, введите новейшую запись, установив пустую запись клавишей перехода►*. Добавленную запись можно проверить в таблице

11. Окончите создание элементанажатием Enterили щелчком вне рамки.

12. Введите в область заголовка еще одну надпись: Казахский экономический институт им. Т.Рыскулова
.

13. Для сохранения формы под новеньким именованием

нужно выполнить команду Файл/Сохранить

14. Перейдя в режим формы
, введите новейшую запись, установив пустую запись клавишей перехода►*. Добавленную запись можно проверить в таблице

Многотабличные формы

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

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

1. В окне базы данных

изберите Формы
/ Сделать

2. Дальше изберите режим Мастер форм
и таблицу

3. Изберите для таблицы

в перечне Доступные поля
— все поля — >>

4. Изберите дальше из перечня Таблицы/Запросы
таблицу

и в перечне Доступные поля
данной для нас таблицы – тоже все поля. Эта таблица будет источником записей подчиненной формы.

5. В окне Создание форм
схематично отобразится макет формы с списком полей в главный части формы и в подчиненной форме, если в рамке Изберите тип
представления данных выделена таблица-источник записей главный части формы (

).

6. Дальше изберите Подчиненные формы

7. Наружный вид
— ленточный

8. Стиль
– Обыденный

9. В крайнем окне Создание форм
озаглавьте главную форму —

и подчиненную форму —

. Изберите Открытие формы
для просмотра и ввода данных и нажмите Готово
.

10. Для редактирования сделанной формы перейдите в Режим конструктора
. Это можно выполнить и в крайнем сеансе окна Создание форм
, выбрав последующие деяния мастера — Поменять макет форм.

11. Введите в область заголовка полное заглавие формы
,
используя клавишу Надпись
и перетащив со перечня полей
. (Если окно со перечнем полей отсутствует, то — Вид|Перечень полей
.) Показавшуюся надпись
выделите и нажмите Del
. Отформатируйте заголовок по собственному усмотрению.

12. Для встраивания клавиши в подходящем месте (рис. на стр. 12) нажмите на панели частей Клавиша
. Опосля переноса клавиши запустится мастер клавиш Создание
клавиш
.

13. В окне мастера клавиш
изберите действие, которое нужно выполнить при нажатии клавиши. В области Группы
изберите Переходы по записям
, в области Деяния
– Предшествующая запись
.

14. В последующем сеансе отметьте Набросок
и показать все картинки
. Сможете избрать Стрелка ввысь
(голубая) и Готово
.

15. Подобные деяния выполняются для встраивания клавиши перехода к следующей записи таблицы. В области Деяния
— соответственно пункт Последующая запись
и набросок Стрелка вниз
(голубая)

16. Добавьте с кнопкамипоясняющий текст: Предшествующая
и Последующая,
при помощи клавиш Надписи
на панели частей.

17. Для сотворения клавиши закрытия формы в области Группы
изберите Работа с
формой
, а в области Деяния
– Закрыть Форму.

18. Для ввода данных в таблицы

и

можно открыть в режиме формы

, которая обеспечит одновременную работу с данными 2-ух таблиц.

19. Для перехода к крайней записи можно употреблять клавишу Последующая
.

20. Введите добавочно группу 106, количество студентов – 2, средний балл — 4 и любые две фамилии с надлежащими данными

21. Закрыть форму

22. Данные проверьте в таблицах

и

Проектирование запросов

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

MicrosoftAccess дозволяет делать последующие типы запросов:

1. QBE- запросы (QueryByExample –Запросы по эталону)

· запрос на подборку;

· Перекрестный запрос;

· Запрос на создание таблицы;

· запрос на обновление;

· Запрос на добавление записей;

· запрос на удаление записей;

· Параметрический запрос.

2. Запросы на языке SQL ( StructuredQueryLanguage – Структурированный язык запросов). SQL – стандартизованная форма составления запросов для обработки реляционных базы данных, представляющая собой последовательность аннотации. При выполнении QBE – запросов они транслируются в надлежащие SQL –запросы.

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

Сделайте запрос, который проверит корректность задания общих часов в таблице

. По запросу должны отбираться лишь те записи, в каких ЧАСЫ
не равно значению, получаемому при сложении значений полей
и
.

1. Изберите объект Запрос
/Сделать

2. В окне Новейший запрос
изберите Конструктор
. В показавшемся окне Добавление
таблицы
изберите таблицу

и нажмите клавишу Добавить
. Избранная таблица будет отображена в области схемы данных
запроса.

3. В окне Конструктора
перетащите (либо два раза щелкните ) из перечня полей таблицы

поля
в столбцы бланка запроса в строчку Поле

4. Если вы по ошибке перетащили ненадобное поле, то выделите столбец и нажмите Del
либо сделайте команду Правка|Удалить столбец

5. В строке Вывод на экран
отметьте поля, по другому они не будут включены в запрос

6. В строке Условие отбора
для столбца
запишите условие

7. Сделайте запрос, нажав на панели конструктора
запросов
клавишу Пуск
либо либо: запрос/Пуск
. На дисплее покажется окно запроса в режиме таблицы с записями из таблицы

, отвечающими данным условиям отбора.

8. Сохраните запрос, нажав клавишу Сохранить
и задав ему имя

9. Закройте текущий запрос

10. Сделайте сохраненный запрос, нажав клавишу Открыть

Обусловьте фактическое число студентов и подсчитайте средний проходной балл в группе.

1. Сделайте в Режиме конструктора
запрос на подборку для таблицы

2. Из перечня полей таблицы перетащите в бланк запроса

3. Нажмите клавишу Групповые операции (Вид/Групповые операции)

4. Поменяйте слово Группировка
в столбце
на Count
, в
— на Avg

5. Поменяйте подпись поля
на
, а
— на

. Для этого из контекстного меню изберите характеристики
. В окне Характеристики поля
наберите в строке Подпись
надлежащие наименования.

6. Для ограничения точности результата 2-мя знаками изберите в окне характеристики поля
для поля
в строке формат поля – Фиксированный

7. Сохраните этот запрос под именованием

Разглядите технологию конструирования многотабличного запроса.

Пусть нужно получить информацию о оценках, приобретенных студентами по всем предметам.

1. В режиме Конструктор
сделайте новейший запрос.

2. В окне Добавление таблицы
изберите

,

,

.

3. Если желаете созидать в бланке запроса вместе с именованием поля к тому же имя таблицы, сделайте команду Вид/Имена таблиц

4. Перетащите в строчку бланка запроса Поле
поля:

·
— из таблицы

·
– из таблицы

5. Если нужно получить информацию о успеваемости определенных студентов, к примеру, Шакиртовой и Бидаралова, введите эти значения в строчку Условие
отбора
записей. Запишите в поле
фамилии студентов в различных строчках бланка запроса, т.к. нужно избрать записи по логике «либо». Так как инициалы студентов не известны, фамилии задайте с внедрением шаблона *. Заметьте, что система сама вставляет оператор Like
, определяющий поиск по эталону.

6. Сделайте запрос и сохраните под именованием ПРЕДМЕТАМ

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

1. Откройте запрос ПРЕДМЕТАМ

в Режиме конструктора
.

В строке Условие отбора
поля
введите воззвание к юзеру в квадратных скобках, к примеру,

3. Для поля
— 2-ой параметр запроса
]

4. Сделайте запрос, задав всякую фамилию из таблицы

и хоть какой предмет из таблицы

Построение запроса на базе остальных запросов

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

1. Сделайте запрос на подборку, в каком по таблице

при помощи функции Count
подсчитывается число педагогов на каждой кафедре. Сохраните запрос под именованием

.

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

и

3. Сохраните запрос под именованием

и сделайте.

4. Для окончательного решения задачки нужно на базе 2-ух прошлых запросов приготовить 3-ий запрос с вычисляемым полем.

5. Сделайте запрос в Режиме конструктора
. В окне Добавление таблицы
откройте вкладку Таблицы и запросы
и изберите таблицу

и два прошлых запроса

6. В строчку Поле
из таблицы

перенесите поля
и
, а из запросов — соответственно Count
_
и Sum
_
. Таблица

включена в запрос для дополнения кода кафедры ее наименованием.

7. Для сотворения вычисляемого поля, рассчитывающего среднюю нагрузку педагога, введите выражение [Sum
_
]/[ Count
_
]. Для этого в строке Поле
пустого столбца при помощи контекстно-зависимого меню вызовите Построитель выражения
, выбрав меню Выстроить
. В левой части окна Построителя выражения
в папке Запросы
изберите надлежащие запросы. Справа отобразится перечень полей. Поочередно выбирая нужные поля, нажимая клавишу Вставить
и вставляя знаки операции, сформируйте нужное выражение в верхней части окна, Ok
.

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

9. Задайте в Подпись
поля Средняя перегрузка педагога
, в формат
поля
— Фиксированный
и в Число десятичных символов
– 0

10. Сохраните запрос под именованием КАФЕДРАМ

запрос на создание таблицы

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

Сконструируйте запрос на создание таблицы на запросе

и

.

1. В окне базы данных выделите нареченный запрос и откройте его в режиме Конструктора

2.
Изберите в меню Запрос|Создание таблицы

3. В окне Создание таблиц
введите имя

и отметьте В
текущей базе данных

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

Запрос на обновление

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

Разглядите технологию формирования на примере обновления поля
(количество студентов группы в таблице

).

1. Для формирования запроса на обновление
поначалу сделайте запрос на подборку
на базе 2-ух таблиц: обновляемой таблицы

и таблицы

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

2. Преобразуйте запрос на подборку
в Запрос на обновление,
выбрав из меню Запрос|Обновление

3. Заполните бланк запроса. Перетащите обновляемое поле
в строчку Поле
. В строчку Обновление
введите
имя поля Count
_
, заключенное в квадратные скобки

4. Просмотрите содержимое поля
перед обновлением в режиме Таблица

5. Сохраните запрос под именованием

.

6. Сделайте запрос

7. Направьте внимание на модифицированные значения содержимого поля
в таблице

Перекрестный запрос

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

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

, которая находится в отношениях один-ко-многим с таблицей

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

и

1. Сделайте при помощи мастера обычной запрос
. В этом запросе изберите из таблицы

поле
, а из таблицы

– поля
и
. Сохраните запрос с именованием

2.
Для сотворения последующего запроса нажмите клавишу Сделать|
Перекрестный запрос

3. В окне мастера изберите запрос

4. В последующем окне мастера изберите для заголовков строк поле
. Для выбора используйте клавишу >.

5. Для заголовков столбцов установлено поле

6. Для вычисления значений ячеек изберите поле
и функцию
(Count
)

В отличие от мастера Конструктор
дозволяет сделать многотабличный перекрестный запрос. Разглядите создание перекрестного запроса, в каком заголовками строк будут фамилии педагогов, заголовками столбцов — наименование предметов, а на пересечении строк и столбцов — сумма часов.

1. Начните, как обычно, создание запроса в режиме Конструктора

2. В окне Добавление таблицы
включите в схему данных таблицы

,

и

В бланк запроса перетащите поля
из таблицы

,
– из таблицы

,
– из таблицы

4. Сделайте команду меню запрос/Перекрестный
. В бланке запроса покажутся две доп строчки Групповая операция
и Перекрестная таблица

5. В строке Перекрестная таблица
для поля
изберите из перечня Заглавия строк
, для
– Заглавия столбцов
, для поля
—

6.
В строке Групповая операция
для поля
изберите Sum
, оставив для всех других полей – Группировка

отчеты

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

Разглядите создание отчета на примере получения списков студентов по группам.

1. Обусловьте требования к макету отчета:

— Списки студентов каждой группы в отчете должны выводиться поочередно совместно с заголовками

— нужно высчитать средний проходной балл для каждой группы

— Записи должны выводиться в алфавитном порядке фамилий

Начните создание отчета при помощи Мастера
, а потом откорректируйте в режиме Конструктора
.

2. На вкладке отчет
нажмите на клавишу Сделать

3. В окне Новейший отчет
откройте перечень таблиц и изберите

, потом — Мастер отчетов

Изберите поля

5. Данные в отчете должны быть сгруппированы по полю

6. В последующем окне мастера обусловьте метод сортировки (в нашем случае по
). Нажмите клавишу Итоги
и изберите для поля
функцию Avg

7. Последующие окна предусмотрены для дизайна стиля и дизайна отчета, которые предлагаем избрать без помощи других

8. По дефлоту отчет воспримет имя

Для редактирования отчета перейдите в Режим конструктора.

1. В разделе Заголовок отчета
из пт контекстного меню характеристики
в строке Подпись
поменяйте заголовок на

, тут же изберите размер шрифта, начертание

2. Из раздела Верхний колонтитул
удалите поле
, чтоб оно не повторялось. Для этого выделите его и Del
. Выбрав из панели частей Надпись,
введите подпись
поля:

Установите подходящий шрифт в элементах.

3. Аналогично поменяйте Подпись
поля в разделе Примечание
группы
на
. В свойствах элемента функции =
Avg
(

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

]]>

Перейти и растаять в своей любимой социалке

Учебная работа. Реферат: Система управления баз данных

Учебная работа. Реферат: Система управления баз данных

Как? Вы еще не читали? Ну это зря...