распознанный текст 1. Теория баз данных Общие понятия
 Скачать 283.55 Kb.
|
|
SELECT 'Номер заказа', 'Номер счета’, 'Дата заказа' FROM 'Заказы' WHERE 'Номер клиента' - 20 Этот запрос обращается к таблице Заказы, и выбирает из нее все записи, принадлежащие клиенту с номером 20, организуя эти записи в три столбца: Номер заказа, Номер счета, Дата заказа. INSERT — оператор добавления данных. Пример: INSERT INTO 'Заказы' VALUES (1420, 20, 'Ускоренная доставка', 1221, 15.03.2010) Этот запрос обращается к таблице Заказы и добавляет к ней запись со значениями полей, перечисленными в скобках после оператора VALUES. UPDATE — оператор изменения данных. Пример: UPDATE 'Заказы' SET 'Номер счета' = 1432 WHERE 'Номер заказа' = 1220 Этот запрос обращается к таблице Заказы и в записи с номером заказа 1220 изменяет значение поля Номер счета на 1432. DELETE — оператор удаления данных. Пример: DELETE FROM 'Заказы' WHERE 'Номер клиента’ = 20 Из таблицы Заказы удаляются строки с номером клиента 20 (то есть все заказы данного клиента). Операторы определения данных Операторы определения данных позволяют манипулировать схемой базы данных, то есть создавать объекты базы данных (таблицы, представления, триггеры, хранимые процедуры, индексы, ключи, ограничения, и т. д.). CREATE (TABLE, VIEW, TRIGGER, INDEX, STORED PROC) — создает указанный объект базы данных. DROP (TABLE, VIEW, TRIGGER, INDEX, STORED PROC) — уничтожает указанный объект базы данных. ALTER (TABLE, VIEW, TRIGGER, INDEX, STORED PROC) — изменяет структуру указанного объекта базы данных. Операторы управления данными К операторам управления данными относятся операторы назначения прав доступа и управления транзакциями, а также операторы создания баз данных и изменения структуры данных. GRANT — предоставляет привилегии пользователям. Пример: GRANT SELECT ON 'Заказы' ТО NEKT0 Разрешает пользователю NEKT0 выполнять запросы на выборку данных к таблице Заказы. При этом пользователь не получает привилегий, позволяющих ему изменять данные в этой таблице или в структуре таблицы. REVOKE — аннулирует привилегии. Пример: REVOKE ALL ON 'Заказы' FROM NEKTO Лишает пользователя NEKTO всех привилегий в таблице Заказы. COMMIT — подтверждает транзакцию. ROLLBACK — отменяет транзакцию. CREATE DATABASE — создает базу данных. ALTER DATABASE — изменяет базу данных. DROP DATABASE — уничтожает базу данных. В данном разделе перечислены только основные операторы языка SQL. Даже в стандартной реализации их гораздо больше. Однако ограничения, накладываемые декларативным характером языка, вынуждают производителей СУБД создавать расширенные версии SQL. Примерами таких расширенных версий могут служить Transact SQL для MS SQL Server или PL/SQL для ORACLE. В этих расширениях в язык включены операторы для организации ветвлений, циклов, и т. д. Преимущества и недостатки реляционной модели Структурная независимость. Поскольку в реляционной модели баз данных навигационная схема доступа к данным не используется, маршрут доступа к данным не имеет значения для проектировщиков, программистов и конечных пользователей реляционной базы данных. Изменения в структуре реляционной БД не влияют на доступ к данным со стороны СУБД. Поэтому в реляционной модели базы данных достигается структурная независимость, не свойственная сетевым и иерархическим моделям. Структурная независимость имеет место, когда изменения в структуре БД не влияют на возможности доступа к данным со стороны СУБД. В отличие от реляционной базы данных, любые изменения в древовидной структуре иерархической базы данных или во множествах баз сетевой БД влияют на маршруты доступа к данным, что требует изменения всех прикладных программ. Концептуальная простота. Реляционная модель на концептуальном уровне проста для понимания. Поскольку реляционная модель позволяет полностью избавиться от подробностей физического хранения данных, пользователи могут полностью сосредоточиться на логическом представлении базы данных, то есть уделять большее внимание естественному представлению о хранении. Простота проектирования, реализации, управления и использования. Поскольку в реляционной модели достигаются и независимость по данным, и структурная независимость, становится проще проектировать базу и управлять ее содержимым. Нерегламентированные запросы. Одним из главных факторов, позволивших реляционным базам данных занять доминирующее положение на рынке, была возможность применять гибкий и унифицированный механизм создания запросов. Для большей части программного обеспечения реляционных БД стандартным языком запросов является язык SQL. SQL относится к так называемым языкам четвертого поколения (4GL), которые дают пользователям возможность определить, что делать, не указывая, как именно это делать. В РСУБД язык SQL применяется при трансляции запроса пользователя в специальный код, необходимый для извлечения запрошенной информации. Следовательно, запросы в реляционной базе данных требуют меньшего программирования, чем в любой другой базе или в файловой системе. Любое SQL-приложение реляционной БД состоит из трех частей: интерфейса пользователя, набора таблиц внутри БД и SQL-машины (SQL-engine). Интерфейс включает в себя систему меню, команды запросов и генераторы отчетов. В основном такой интерфейс дает возможность конечному пользователю взаимодействовать с данными. С помощью генераторов приложений, которые сегодня являются стандартными средствами, входящими в состав многих РСУБД, пользователь может разрабатывать собственные интерфейсы. В значительной степени скрытая от конечного пользователя SQL-машина выполняет большую работу. Внутри РСУБД SQL-машина служит для создания структуры таблиц, обслуживания словаря данных и системного каталога, обеспечения доступа к таблицам БД, а также для трансляции запроса пользователя в формат, пригодный для обработки компьютером. Мощная система управления базой данных. Хорошая РСУБД является более сложной частью программного обеспечения, нежели СУБД иерархических и сетевых баз данных. Это связано с тем, что она решает гораздо больше (и значительно более сложных) задач как для проектировщиков, так и для пользователей. РСУБД полностью скрывает физический уровень сложности системы от проектировщика и конечного пользователя. Несмотря на существенные преимущества реляционной модели перед иерархической или сетевой, она имеет некоторые недостатки. Один из них — это существенные требования к оборудованию и системному программному обеспечению. На самом деле это не столько недостаток, сколько вполне справедливая плата за те преимущества, которые получают пользователи, программисты и администраторы. Постреляционные модели и базы данных По мере того как практические задачи приобретают все более сложный и комплексный характер, а информационные системы все больше склонны проявлять интеллектуальное поведение при взаимодействии с окружающим миром, необходимы более совершенные модели данных. Такие модели должны точнее описывать окружающий мир: уже не в терминах наборов данных, а в терминах объектов, обладающих свойствами, состояниями и поведением. Первой из таких моделей стала семантическая модель данных (Semantic Data Model, SDM), разработанная M. Хаммером и Д. Маклеодом в 1981 г. SDM позволяет моделировать как данные, так и их отношения в единой структуре, называемой объектом. Поскольку основной структурой модели является объект, модель SDM получила название объектно-ориентированной модели данных (Object-Oriented Data Model, OODM). В свою очередь, OODM стала основой для создания объектно-ориентированной модели базы данных (OODBM), управление которой осуществляется с помощь системы управления объектно-ориентированной базой данных (ООСУБД или OODBMS). Объект может включать в себя все данные о себе, связи с другими объектами и операции, которые могут выполняться с объектом (или выполняться объектом). Таким образом, объекты в усовершенствованной модели SDM стали похожи на объекты, создаваемые объектно-ориентированными языками. Это, в свою очередь, обеспечило возможность сближения и тесной интеграции различных групп разработчиков, как проектировщиков и архитекторов базы данных, так и программистов, разрабатывающих пользовательские программы. Р  Пользовательские интерфейсы Функции поддержки Структуры программы Поток работ Структуры классов “  Схемы  исунок 6.17 иллюстрирует такую методологию работы, когда различные группы разработчиков, вовлеченные в процесс обеспечения работы ООСУБД, используют общий репозиторий (хранилище) классов для решения различных задач на различных этапах работы над проектом.
| ||||||||||||