Клиенты и серверы в среде SQL

Содержание:

1. Концепция баз данных. Основные понятия…………………………..2

2. Архитектура банка данных…………………………………………….9

3. Функциональные, инфологические и

даталогические модели предметной области…………………………..13

4. Этапы проектирования  базы данных………………………………...15

5. Основные операции над данными……………………………………17

6. Реляционная модель данных. Отношения и схемы отношений.

Основные операции над  отношениями…………………………………18

7. Сетевая модель данных………………………………………………..22

8. Иерархическая модель данных………………………………………..24

9. Стадии и этапы разработки базы данных…………………………….27

10. Языки реляционной алгебры и исчисления отношений…………...30

11. Методы нормализации схем отношений……………………………31

12. Инструментальные средства разработки баз данных………………34

13. Запросы в языке SQL…………………………………………………36

14. Клиенты и серверы в среде SQL……………………………………..39

16. Список используемой литературы…………………………………..40

Концепция баз  данных. Основные понятия.

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

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

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

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

StockNo Description Level Re_Order_Level Unit_Cost

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

Customer_Name Address InvoiceNo ItemNo Description Amount ltem_Cost

Order_Cost CrediMJmit

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

Customer_Name InvoiceNo Order_Cost PaymenMReceived CrediMJmit

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

1. Неоднозначность. В приведенном  выше примере возникает ситуация, когда один и тот же элемент  по-разному называется в разных  файлах. Так, возникает вопрос, StockNo в файле запасов и ItemNo в файле счетов одно и то же или нет? Успешная работа предприятия предполагает отсутствие подобных неоднозначностей.

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

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

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

Рис. 1. Совместное использование данных приложениями

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

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

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

Рис. 2. Интегрированная система с базой данных

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

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

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

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

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

Таким образом, СУБД обеспечивает следующие возможности:

1. Интеграцию и совместное  использование данных различными  приложениями.

2. Способность поддерживать  разнообразные представления одних  и тех же данных.

4. Гарантию безопасности  и целостности данных.

Система с базой данных состоит из следующих компонентов:

1. Пользователи. Это люди, которые используют данные.

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

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

4. Данные. Строки данных, хранящиеся в файлах.

5. Система-хост. Это компьютерная  система, в которой хранятся  файлы.

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

рис. 3

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

Архитектура банка  данных.

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

• инфологический уровень;
• концептуальный уровень;
• внешний уровень;
• внутренний уровень.

На каждом уровне присутствует модель данных информации, которая  специфицируется с помощью языка  описания данного уровня. Модель каждого  уровня, представленную на языке описания, принято называть СХЕМОЙ. Перевод моделей (описаний моделей) из одного уровня в другой осуществляется с помощью трансляции или интерпретации.

B зависимости от вида  представления информации различают  следующие типы схем:

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

Согласно предложениям ANSI/SPARC, к исследованию разнотипных БД можно  подходить с единых позиций, если придерживаться следующей архитектуры  банка данных (рис. 4). 

Рис. 4. Архитектура банка данных

Архитектура представлена тремя  уровнями: внутренним, концептуальным и внешним.

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

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

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

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

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

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

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

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

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

 Функциональные, инфологические и даталогические модели предметной области.

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

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

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