Hi! My name is Damir. I’m co-founder at IFAB.ru and i’m pretty good at these scary things

  • Startups
  • E-Commerce
  • Process development
  • Process implementation
  • Project management
  • Financial modeling
  • Business strategy

You can reach me out via these networks

Are you hiring? Check out my CV

My CV page

Базы Данных

Вернуться к основной странице Вышки
[anti-both]

Шпаргалка по командам и таблицам

1) Понятия банка данных. Преимущества и недостатки

«Банк данных – это система специальным образом организованных данных (баз данных), программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных»

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

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

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

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

 

2) Компоненты банков данных и их краткая характеристика

 

 

 

 

 

 

таблица

 

 

 

1. Информационная компонента

Ядро банка данных  – база данных. База данных – поименная совокупность взаимосвязанных данных, находящихся под управлением СУБД. В настоящее время действует закон РФ “О правовой охране программ для электронных вычислительных систем и баз данных”, по нему: База данных – это объективная форма представления и организации совокупности данных, систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.

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

2. Программные средства банка данных

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

3. Языковые средства банков данных

Языковые средства обеспечивают интерфейс пользователей разных категорий с банком данных. Большинство языковых средств современных СУБД относятся к языкам 4-ого поколения(смотреть вопрос 6!!). Можно выделить 2 концепции развития языковых средств: концепция разделения и концепция интеграции. При использовании концепции разделения различают ЯОД(языки описания данных) и ЯМД(языки манипулирования данными), иногда выделяют языки запросов. Языки манипулирования разделяют на процедурные и непроцедурные(декларативные). Более подробно ответ на эту часть в вопросе №3!

4. Технические средства банков данных

Состав технических средств стандартный: ЭВМ, периферийные средства для ввода информации в базу данных, средства отображения вводимой информации. Если банк реализуется в сети, то необходимы коммуникационные средства.

5. Организационно-методические средства

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

6. Администраторы банка данных

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

3) Языковые средства СУБД

1. Data Definition Language (DDL) (язык описания данных) — это семейство компьютерных языков, используемых в компьютерных программах для описания структуры баз данных.

Язык DDL позволяет описывать и создавать такие объекты базы дан­ных, как таблицы, индексы, представления и др

На текущий момент наиболее популярным языком DDL является SQL, используемый для получения и манипулирования данными в РСУБД, и сочетающий в себе элемены DDL и DML.

2. Data Manipulation Language (DML) (язык управления (манипулирования) данными) — это семейство компьютерных языков, используемых в компьютерных программах или пользователями баз данных для получения, вставки, удаления или изменения данных в базах данных.

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

Языки DML разделяются в основном на два типа: Procedural DMLs — описывают действия над данными. Declarative DMLs — описывают сами данные.

3. Transact-SQL (T-SQL) — процедурное расширение языка SQL компаний Microsoft (для Microsoft SQL Server) и Sybase (для Sybase ASE).

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

Язык Transact-SQL является ключом к использованию MS SQL Server. Все приложения, взаимодействующие с экземпляром MS SQL Server, независимо от их реализации и пользовательского интерфейса, отправляют серверу инструкции Transact-SQL.

4. PL/SQL (Procedural Language / Structured Query Language) — язык программирования, процедурное расширение языка SQL, разработанное корпорацией Oracle. Базируется на языке Ада.

PL/SQL даёт возможность использовать переменные, операторы, массивы, курсоры и исключения. Начиная с версии 8 посредством использования Oracle RDBMS стала доступна и объектно-ориентированная модель.

5. ANSI SQL

Первый официальный стандарт языка SQL был принят ANSI в 1986 году и ISO (Международной организацией по стандартизации) в 1987 году (так называемый SQL-86) и несколько уточнён в 1989 году. Дальнейшее развитие языка поставщиками СУБД потребовало принятия в 1992 году нового расширенного стандарта (ANSI SQL-92 или просто SQL2). Следующим стандартом стал SQL:1999 (SQL3). В настоящее время действует стандарт, принятый в 2003 году (SQL:2003) с небольшими модификациями, внесёнными позже.

4. Тенденции развития СУБД

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

1. Поддержка разных стилей проектирования (традиционный, объектно-ориентированный, «визуальное» проектирование).Использование визуальных объектно-ориентированных средств разработки является преобладающей тенденцией.

2. Использование мультимедийных систем. Обработка графических образов. Управление пространственной информацией.

3. Повышение уровня языковых средств. Дружелюбность.

4. Включение в СУБД разнообразных языковых средств, ориентированных на разные категории пользователей.

5. Поддержка решений для реализации хранилищ данных в целях обеспечения процессов принятия решений.

6. Наличие разнообразных сервисных средств (развитая «помощь»: контекстная помощь (Help), электронные учебники, примеры, шаблоны распространенных приложений, «Волшебники» и т.п.).

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

8. Многоплатформенность – наличие вариантов «одноименных» СУБД, реализованных для разных операционных систем и разных типов компьютеров.

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

10. Использование более развитых и разнообразных средств обеспечения целостности и безопасности данных.

11. «Интернационализация». Выражается в использовании СУБД ведущих производителей в разных странах мира; со стороны производителя это проявляется в локализациях версий. Поддержка национальных языков (Спецификация NLS – National Language Support).

12. Работа в многопользовательской среде. Распределенность. Работа в гетерогенной среде. Масштабируемость.

13. Открытость системы. Обеспечивается поддержкой определенных стандартов.

14. Преобладающая модель данных – реляционная.

15. Преобладающий язык запросов – SQL. Это тоже говорит о повышении уровня реляционности.

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

17. Развитие объектно-реляционных и объектно-ориентированных СУБД.

18. Развитие средств обеспечения безопасности данных.

19. Развитие средств упрощения эксплуатации баз данных. Управление базой данных в значительной степени автоматизировано.

20. Повышение качества CASE-средств. Широкое использование CASE-средств в практике проектирования и перепроектирования БнД.

21. Широкое использование графических интерфейсов; визуализация процессов проектирования и управления системой.

5) Характеристика современных реляционных СУБД

 

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

набор инструментов для создания таблиц и отношений между связанными таблицами;

средства администрирования базы данных;

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

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

 

MS ACCESS

Основные компоненты MS Access:

построитель таблиц;

построитель экранных форм;

построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

MS Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры. Опыт показывает, что даже для проектов на 5-20 пользователей предпочтительно использовать клиент-серверные решения.

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

 

 

MS SQL Server

Microsoft SQL Server — система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

 

Oracle

Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных (СУБД). MVCC (англ. MultiVersion Concurrency Control) Многоверсионность данных для управления параллельными транзакциями

Секционирование

Автономные транзакции

Automatic Storage Management Автоматическое управление хранением файлов БД

Пакеты[4]

sequence

Аналитические функции[5]

Profile manager

Oracle Label Security[6]

Streams[7]

Advanced Queuing

Flashback Query

RAC (англ. Real Application Clusters)

Объектно-ориентированные свойства

Automatic Database Diagnostic Monitoring — Автоматический мониторинг и диагностика БД для выявления проблем производительности и, возможно, автоматической корректировки (если таковая определена администратором)

Подсказка в SQL-запросе (иначе Хинт)

 

6) Языки 4-ого поколения и их реализация в современных СУБД

Языковые средства большинства современных СУБД относятся к языкам 4-го поколения (к 1-му поколению языков относят машинные языки, ко 2-му – символические языки ассемблера, к 3-му – алгоритмические языки типа PL, Cobol и т.п., которые в 1960-е гг. назывались языками высокого уровня, но уровень, которых гораздо ниже, чем у языков 4-го поколения. Имеются еще и языки 5-го поколения, к которым относят языки систем искусственного интеллекта, например Prolog).

Языки 4-го поколения создавались по принципу: «люди стоят дороже, чем машины». При их проектировании использовались следующие принципы.

1. Принцип минимума работы: язык должен обеспечить минимум усилий, чтобы «заставить» машину работать.

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

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

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

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

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

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

На рис. 1.7 приведены компоненты языка 4-го поколения. Как видим, здесь представлены все основные «генераторы», наличие которых уже стало традиционным для СУБД разных классов.

2

Рис. 1.7. Компоненты языка 4-го поколения

7) Этапы проектирования баз данных

Начальным шагом проектирования ИС является построение инфологической модели предметной области. Предварительная инфологическая модель строится еще на предпроектной стадии и затем уточняется на более поздних стадиях проектирования. Затем на ее основе строится даталогическая модель. Физическая и внешняя мо­дели после этого могут строиться в любой последовательности по отношению друг к другу, в том числе и параллельно.

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

3

Рис. 1.22. Взаимосвязь этапов проектирования

8 )  Пользователи банков данных.

В процессе эксплуатации БнД с ним взаимодействуют пользователи разных категорий.

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

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

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

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

Кроме конечных пользователей, с БнД работают сотрудники информационных служб. Они работают в основном с метаинформацией и они используют БнД для выполнения своих функций, и другая информация чаще всего от них закрыта. Также в эту категорию входят «Администраторы БнД» – лица, ответственные за создание БнД и его надежное функционирование и обладающие высоким уровнем доступа.

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

9) Функции администраторов банков данных.

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

Функции администратора банка данных.

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

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

3. Задание ограничений целостности: задание ограничений целостности предметной области; определение ограничений целостности, вызванных структурой базы данных; разработка процедур обеспечения целостности БД при вводе и корректировке данных; обеспечение ограничений целостности при параллельной работе пользователей.

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

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

6. Защита данных от разрушений. Например, резервированием.

7. Обеспечение восстановления БД: разработка программно-технологических средств восстановления БД, организация ведения системных журналов.

8. Анализ обращений пользователей к БД: сбор статистики обращений пользователей к БД, ее хранение и анализ.

9. Анализ эффективности функционирования БнД и развитие системы: анализ показателей функционирования системы (время обработки, объем памяти, стоимостные показатели), реорганизация и реструктуризация баз данных, изменение состава баз данных, развитие программных и технических средств.

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

11. Подготовка и поддержание системных программных средств: сбор и анализ информации о СУБД и других программных продуктах (ПП), приобретение программных средств, их установка, проверка работоспособности, поддержание системных библиотек, развитие программных средств.

12. Организационно-методическая работа: выбор или создание методики проектирования БД, определение целей и направлений развития системы, планирование этапов развития БнД, разработка и выпуск организационно-методических материалов.

Средства администратора современных СУБД.

Существуют также автоматизированные средства администрирования DBA (DataBase Administration – администрирование базы данных). Типичными функциями средств DBA являются: мониторинг работы БД, реакция на нештатные ситуации, оптимизация хранения данных, оптимизация работы сервера, сопровождение БД, файлов, табличных пространств.

 

10) Технические средства банков данных.

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

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

В качестве ЭВМ для банков данных чаще всего используются универсальные компьютеры.

Первоначально БнД реализовывались в основном на больших ЭВМ, а для доступа к БД использовались терминалы. В связи со значительным и постоянным улучшением характеристик персональных ЭВМ появилась возможность реализовать банки данных и на машинах этого класса.

В 1990-е гг. некоторые фирмы (Oracle, Sun) активно развивали идею применения так называемых «сетевых компьютеров». Эти компьютеры представляют собой дешевые рабочие станции без дисковых накопителей, которые предназначены для работы в сети, и предполагают использование программных средств и данных, находящихся на сервере. Использование сетевых компьютеров предполагает обязательное применение мощных ЭВМ в качестве серверов, предъявляет высокие требования к организации хранения данных, к качеству каналов связи, что делает систему уязвимой. При этом во многом становится предопределенной технология обработки данных, из-за чего система теряет возможность обеспечить потребности всех пользователей.

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

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

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

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

 

11) Инфологическое моделирование.

Для того чтобы спроектировать структуру базы дан­ных, необходима исходная информация о предметной области в формализован­ном виде. Такое формализованное описание предметной области (ПО) называется инфологической (infological) моделью предметной области (ИЛМ) или концептуальной моделью (КМ). Концепту­альная схема должна отражать специфику предметной области, а не структуру БД, и поэтому она  представляет собой описание предметной области, вы­полненное без жесткой ориентации на используемые в дальнейшем программные и технические средства.

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

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

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

2. Особенности требуемой обработки информации: характеристика запросов; требования к защите информации.

3. Характеристика пользователей системы: число пользователей; приоритеты пользователей; необходимость работы в распределенной среде.

4. Состояние существующей системы обработки информации.

5. Возможности, предоставляемые используемыми техническими и программными средствами: поддерживаемые структуры данных; ограничения по объему памяти; быстродействие технических средств; производительность программного обеспечения.

6. Трудоемкость проектирования.

7. Финансовые возможности.

8. Квалификация кадров: разработчиков; пользователей.

9. Используемые методики проектирования.

10. Субъективные факторы: мода; привычки и предпочтения.

Основными компонентами концептуальной модели ПО являются:

• описание объектов ПО и связей между ними (этот пункт оказывает наибольшее влияние на проектирование структуры базы данных);

• описание информационных потребностей пользователей;

• описание существующей информационной системы;

• описание алгоритмических зависимостей показателей;

• описание ограничений целостности;

• описание функциональной структуры системы, для которой со­здается АИС;

• требования к ИС и существующие ограничения;

• лингвистические отношения.

К концептуальной модели предъявляются следующие требования:

  1. адекватное отображение предметной области;
  2. непротиворечивость;
  3. однозначная трактовка модели всеми ее пользователями;
  4. легкость восприятия разными категориями пользователей;
  5. конечность модели;
  6. легкость модификации;
  7. возможность композиции и декомпозиции модели.

Чаще всего описание объектов ПО и связей между ними представляется в виде так называемых ER-моделей (или ER-диаграмм) (ER = Entity-Relationship = сущность-связь).

12) Сравнение методик ER-моделирования.

ER-модели широко используются в практике создания баз дан­ных, но при этом методики ER-моделирования различных CASE-систем отличаются от «классической» методики моделирования инфологической модели и различаются между собой.

Прежде всего, рассмотрим отличия «базовой» методики моделирования предметной области от используемых в CASE-системах. Принципиально важным является решение вопроса о том, что же отражает ER-модель. Во методологиях многих CASE-средств хотя считается, что ER-модель является кон­цептуальной моделью БД, на самом деле она является не описанием предметной области, а реляционной БД. Поэтому рекомендуется строить две ER-модели: первая будет отображать предметную область, безотносительно к тому, что будет храниться в базе данных, а вторая – содер­жать только те элементы, которые будут храниться в БД.

В данном случае важна специфика языка построения ER-модели в конкретной CASE-системе. Так, например, во многих системах нет понятия «условного свойства», т.е. свойства, которое может присутствовать не у всех объектов класса. В данном случае, например, в методологиях типа IDEF1X возможно несколько вариантов: условное свойство изображать как обычный атрибут; объект, обладающий условным свойством, изобразить как обоб­щенный объект; или выделить «обладание свойством» в отдельный объект.

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

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

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

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

К несущественным различиям можно отнести терминологические расхождения  и различия в условных обозначениях различных СASE-средств, т.е. различных обозначениях сущностей (прямоугольники, блоки с закругленными углами, овалы и т.п.) и связей (стрелки, лапки, точки и т.п.). Поскольку рассматриваемые различия не являются существенны­ми, то легко выполнить преобразование из одной формы представле­ния в другую, что и позволяют автоматически делать многие CASE-средства.

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

13)  Design/IDEF. Виды сущностей и их создание.

Design/IDEF является комплексной системой автоматизации про­ектирования ИС. Она объединяет в себе несколько методологий, каж­дая из которых предназначена для построения моделей определенно­го типа. Для построения ER-модели используется методология IDEF1X.

Построение новой ER-модели можно начать только с создания новой сущности. После создания новой сущности и указания её имени, система автоматически присваи­вает ей уникальный идентификатор (Entity ID). Кроме ос­новного имени можно задать еще и псевдоним (Aliases) – имя, ис­пользуемое в качестве синонима. Также можно задать описание сущности. Такие описа­ния важны для документирования модели, уточнения терминологии, используемой в проекте, но на проектировании структуры базы дан­ных они не скажутся.

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

При преобразовании ER-модели в схему реляционной базы данных в Design/IDEF каждой сущности ста­вится в соответствие таблица реляционной базы данных, и при опи­сании сущности требуется определить, какой атрибут (или несколько атрибутов) выбран в качестве первичного ключа (Primary Key). Если несколько атрибутов указаны как первичные ключи, значит каждый из них является элементом составного ключа.

Если есть несколько альтернативных (вероятных) ключей, то нуж­но все описать их как альтернативные (Alternate Key). Так как вероят­ных ключей может быть несколько, то необходимо поставить порядковый номер каждого. Если аль­тернативный ключ является составным, то все составляющие его ат­рибуты следует пометить одним и тем же номером.

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

Таким образом создаются простые объекты. Как мы помним, существуют также сложные объекты следующих видов: составные, обобщенные и агрегированные.

Составной объект соответствует отображению отношения «целое-часть». Поскольку в Design/IDEF нет возможности отображать составные свойства, то нужно либо описать это составное свойство как один атрибут, либо каждый из составляющих его элементов описать как отдельный атрибут.

Обобщенный объект отражает наличие связи «род-вид» между объектами предметной области. Отображение обобщенного объекта в Design/IDEF осуществляется следующим образом. То свойство, по которому классы делятся на подклассы, обозначается при описании дискриминатором (Discriminator). После этого каждо­му подклассу ставится в соответствие отдельная сущность, в которой перечисляются атрибуты, присущие этому подклассу. Далее дискримина­тор связывается с видовыми сущностями при автоматической миграции ключа и подчиненные сущности стано­вятся, таким образом, зависимыми от идентификации сущностями.

Агрегированные объекты соответствуют обычно какому-либо процессу, в который оказываются вовлеченными другие объекты. Для изображения агрегированных объектов в Design/IDEF не пре­дусмотрено никаких специализированных изобразительных средств, поэтому их следует отобра­жать следующим образом: соединить сущность  идентифицирующими связями с сущностями, уча­ствующими в данном процессе; если для полной идентификации изображаемой сущности миг­рировавших ключей оказывается недостаточно, то дополнительные атрибуты при их описании нужно задать как первичный ключ; описать остальные атрибуты.

14. Design/IDEF. Виды связей.

Design/IDEF является комплексной системой автоматизации про­ектирования ИС. Она объединяет в себе несколько методологий, каж­дая из которых предназначена для построения моделей определенно­го типа. Для построения ER-модели используется методология IDEF1X.

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

Для каждой связи должен быть определен тип связи (Relationship Туре) и кардинальное число (Relationship Cardinality).

В Design/IDEF различают следующие типы связи:

  • Identifying (идентифицирующая);
  • Non-Identifying (неидентифицирующая);
  • Non-Specific (неспецифическая).

Идентифицирующая и неидентифицирующая связи представля­ют собой связи 1:М. Первая из них используется, если связь направ­лена к независимой по идентификации сущности, вторая – к зависимой. Неспецифическая связь представляет собой связь М:М между объектами. Так как алгоритм проектирования БД в Design/IDEF не обеспечивает автоматического преобразования свя­зей М:М, то перед генерацией описания БД необходимо устранить неспецифические связи и преобразовать их в специфические. Для этого нужно ввести дополнительную связующую сущность.

Идентифицирующая и неидентифицирующая связи отличаются тем, куда мигрирует ключ исходной сущности: в первом случае он становится ча­стью ключа «целевой» сущности, а во втором – неключевым атрибутом (но в обоих случаях это внешний ключ). Идентифицирующую связь нельзя провести, если у ис­ходного объекта не задан ключ.

Надо помнить, что реляционные СУБД не поддерживают связи М:М, поэтому такие связи надо переопределять. – прим. ред.

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

  • каждый экземпляр сущности-родителя может иметь нуль, один или более одного связанного с ним экземпляра сущности-потомка (Zero, One or Many);
  • каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка (Zero or One [Z]);
  • каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка (One or Many [P])
  • каждый экземпляр сущности-родителя связан с некоторым фик­сированным числом экземпляров сущности-потомка (Exactly).

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

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

15) Design/IDEF. Особенности построения ER-модели.

Построение ER-модели является центральным моментом про­ектирования автоматизированных информационных систем при ис­пользовании соответствующих технологий.

В Design/IDEF при преобразовании ER-модели в описание целе­вой базы данных каждому объекту ставится в соответствие таблица реляционной базы данных. Поэтому в Design/ IDEF нужно сначала определить не просто то, что будет храниться в базе данных, а с уточнением, что будет храниться в отдельной табли­це, и с учетом этого строить модель. В качестве объектов ER-модели следует изображать только те сущности, которым будут соответство­вать отдельные таблицы. Другой путь – сначала построить предвари­тельную ER-модель, а потом ее преобразовать к варианту, который будет служить исходным для генерации схемы базы данных. Все ат­рибуты или сущности, соответствующие вычисляемым значениям, которые проектировщик не хочет хранить в базе данных, должны быть устранены из конечной ER-модели.

В Design/IDEF набор выразительных средств, пре­доставляемых для построения ER-модели, невелик.

Основным элементом модели является сущность (Entity). Сущ­ность имеет имя. Для сущностей описываются их атрибуты. Атрибут может играть роль первичного ключа (Primary Key), альтернативного ключа (Alternate Key), дискриминатора (Discriminator) и инверсного входа (Inversion Entry) либо не играть ни одну из них. Эти характеристики атрибутов отражают совершенно разные аспекты как предметной области, так и организации данных; некоторые из этих показателей жестко привязаны к реляцион­ной модели (понятия первичного и альтернативного ключа); выбор большинства характеристик должен являться результатом про­ектных решений, обычно выполняемых на основе анализа разнооб­разных факторов; ряд характеристик, которые можно отобразить в базовой ER-модели, с которой будет идти дальнейшее сравнение, в методологии IDEF1X в явном виде отобразить нельзя.

В Design/IDEF при преобразовании ER-модели в описание целе­вой базы данных каждому объекту ставится в соответствие таблица реляционной базы данных.

Построение ER-модели всегда начинается с рисования сущности. Иначе не получится ничего к ней привязать. Поэтому создание сущности – обязательный первый шаг проектирования модели – прим. ред.

В Design/IDEF нет изобразительных средств для обозначения множественного свойства, составного свойства, нельзя показать, что свойство может присутствовать не у всех экземпляров объектов, нет понятия агрегированного объекта, нет изобразительного средства для отображения альтернативной связи («арк»). Все это нужно отобра­зить, пользуясь имеющимися в наличии изобразительными средствами.

Если простой объект в Design/IDEF имеет несколько возможных идентификато­ров, то из них следует выбрать тот, который будет использоваться в качестве первичного ключа таблицы, и описать его как Primary Key. Для остальных возможных идентификаторов надо определить, есть ли необходимость проверять их уникальность в процессе веде­ния базы данных. Те идентификаторы, для которых это необходимо делать, нужно обозначить как Alternate Key (AK).

Если объект имеет неуникальное имя, то его следует описать как Inversion Entry (IE), поскольку имя часто используется для поиска. В качестве инверсных входов могут быть описаны и другие атрибуты.

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

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

Отсутствие понятия «условное свойство» приводит к сложностям при моделировании предметной области. Возможны несколько вари­антов выхода из сложившейся ситуации.

1. Никак в ER-модели не отражать, что свойство условное, и опи­сывать его как обычный атрибут.

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

3. Объект, содержащий условные свойства, отображать как обоб­щенный. Каждому условному свойству будет соответствовать катего­рия объектов.

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

В Design/IDEF можно отобразить многоаспектную и многоуров­невую классификацию объектов.

Для изображения агрегированных объектов в Design/IDEF не пре­дусмотрено никаких специализированных изобразительных средств. Агрегированные объекты (процессы) в Design/IDEF следует отобра­жать следующим образом:

1)создать сущность, соответствующую данному объекту;

2)соединить ее идентифицирующими связями с сущностями, уча­ствующими в данном процессе;

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

4) описать остальные атрибуты.

Для определения связи в Design/IDEF надо комбинировать воз­можности, задаваемые в Relationship Type и Relationship Cardinality.

Идентифицирующая (Identifying) и неидентифицирующая (Non-Identifying) связи в общем случае соответствуют отношению 1:М.

Множественная связь называется в Design/IDEF неспецифической (Non-Specific). Так как алгоритм проектирования БД в Design/IDEF не обеспечивает автоматического преобразования свя­зей М:М, то перед генерацией описания БД необходимо устранить неспецифические связи и преобразовать их в специфические. Для этого нужно ввести дополнительную связующую сущность. Никаких атрибутов для нее определять не надо. Далее следует связать вновь введенную сущность с ранее существовавшими объектами иденти­фицирующей связью.

В Design/IDEF выделяют две группы характеристик: Relationship Туре и Relationship Cardinality. В связи с этим не все сочетания, которые можно передать в базовой модели, удается отобразить в Design/IDEF. В Design/IDEF при задании неспецифической свя­зи кардинальность связи указать нельзя. Поэтому в Design/IDEF нельзя отобразить ситуации, когда при связи М:М наблюдается необязатель­ный класс принадлежности со стороны одной из сущностей или со стороны обеих сущностей. Кроме того, в Design/IDEF нет возможно­сти отобразить класс принадлежности сущностей, к которым направ­лена связь.

Рис. 2.70. Типы связи и класс членства. Соответствие базовой модели и Design/IDEF1X

На построение ER-модели оказывает влияние алгоритм проекти­рования базы данных. В Design/IDEF каждой сущности ER-модели соответствует таблица в реляционной базе данных. Поэтому необхо­димо уже на стадии ER-моделирования решить, каким сущностям ставить в соответствие таблицы, а каким – нет, и в качестве объектов ER-модели изображать только те сущности, которым будут соответ­ствовать отдельные таблицы. Например, «дату» не нужно отображать как отдельную таблицу, поэтому эту сущность следует из модели уб­рать. Все атрибуты или сущности, соответствующие вычисляемым значениям, которые проектировщик не хочет хранить в базе данных, тоже должны быть устранены из ER-модели.

В Design/IDEF можно нарисовать несколько связей между парой объектов. При этом на схеме миграция ключа происходит только один раз, а не столько раз, сколько связей объявлено между парой объек­тов.

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

  • исходную, описывающую предметную область безотноситель­но к заложенному в CASE-системе алгоритму преобразования ER-модели в логическую модель целевой базы данных;
  • ER-модель, которая будет использоваться для генерации схемы базы данных.

Поскольку Design/IDEF не производит преобразование имен сущ­ностей и атрибутов в соответствии с требованиями целевой СУБД, то в модели, предназначенной для генерации схемы базы данных, имена сущностям и атрибутам следует давать такие, которые допустимы в целевой СУБД.

В связи с тем, что изобразительные средства ER-моделирования в Design/IDEF бедны, процесс моделирования предметной области не является естественным. Практически специалист, строящий ER-модель в среде Design/IDEF, должен выполнить проектирование струк­туры реляционной базы данных вручную. Подобные средства спо­собствуют решению некоторых проблем, стоящих при создании и развитии ИС, но не облегчают задачу проектирования структуры базы данных.

 

16) Особенности проектирования баз данных в современных реляционных СУБД

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

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

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

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

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

После указания типа поля обычно указывается его длина. Для не­которых типов полей длина предопределена и устанавливается систе­мой автоматически.

Многие реляционные системы позволяют при описании структу­ры файла БД указать и признаки индексирования по отдельным по­лям или по совокупности полей (составной индекс).

Индексация представляет собой способ логической упорядочен­ности файлов.

Кроме индексации по одному полю можно проводить индекса­цию по совокупности полей (составной индекс) или по более слож­ному выражению.

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

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

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

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

Многие СУБД предоставляют возможность использовать и иные способы создания таблиц, не предполагающие непосредственного описания каждого поля проектировщиком.

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

 

 

17)  Даталогическое моделирование.

Модель даталогическая (datalogical) (ДЛМ) – логическая модель БД в терминах конкретной СУБД; отображение логических связей между элементами данных

В ERWin это физическая модель – прим. ред.

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

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

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

Все шаги проектирования даталогической модели выполняются итеративно. Причем вероятны итерации не только внутри стадии даталогического проектирования, но и с «захватом» других стадий про­ектирования БД.

Конечным результатом даталогического проектирования является описание логической структуры базы данных на ЯОД. (в нашем случае – скрипт на SQL Для генерации БД – прим. ред.)

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

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

 

18) Факторы, влияющие на проектирование баз данных.

1. Специфика предметной области:

  • особенности отображаемых объектов, характер связи между объектами предметной области;
  • «размер» системы (объем хранимых данных).

2. Особенности требуемой обработки информации:

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

3. Характеристика пользователей системы:

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

4. Состояние существующей системы обработки информации:

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

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

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

6. Трудоемкость проектирования.

7. Финансовые возможности.

8. Квалификация кадров:

  • разработчиков;
  • пользователей.

9. Используемые методики проектирования:

  • наличие средств автоматизации проектирования;
  • используемый алгоритм проектирования.

10. Субъективные факторы:

  • мода;
  • привычки и предпочтения.

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

 

19)  Виды связей между объектами и их отражение в даталогической модели

Виды связи:

  • идентифицирующая связь «один ко многим»
  • неидентифицирующая связь «один ко многим»
  • связь «многие ко многим»

Идентифицирующая и неидентифицирующая связи представля­ют собой связи 1:М. Первая из них используется, если связь направ­лена к не зависимой по идентификации сущности, вторая – к зависимой.

Не все виды связей, существующие в предметной области, могут быть непосредственно отображены в конкретной даталогической мо­дели. Так, многие СУБД не поддерживают непосредственно отноше­ние М:М между элементами. В этом случае в даталогическую модель вводится дополнительный вспомогательный элемент, отображающий эту связь (таким образом, отношение М:М как бы разбивается на два отношения 1:М между этим вновь введенным элементом и исходны­ми элементами).

Универсальный способ отображения связи между объектами – введение вспомогательного связующего файла, содержащего иденти­фикаторы связанных объектов. Ключ этого отношения будет состав­ным. Такое решение является практически единственно приемлемым при наличии связи М:М между объектами. Дополнительный довод в пользу такого решения – наличие необязательного класса членства объекта в связи. Во многих случаях можно использовать другие, бо­лее эффективные способы отображения связей в структуре БД. Если между объектами предмет­ной области имеется связь М:М, то для хранения такой информации потребуются три отношения: по одному для каждой сущности и одно дополнительное – для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов. Ключ этого отношения будет составным.

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

 

20) Организация баз данных в реляционных СУБД

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

Отображение простых объектов

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

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

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

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

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

Отображение связи между объектами

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

Отображение связи типа М:М. Если между объектами предмет­ной области имеется связь М:М, то для хранения такой информации потребуются три отношения: по одному для каждой сущности и одно дополнительное – для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов. Ключ этого отношения будет составным.

Отображение связи типа 1:М. Если между объектами предмет­ной области имеется связь 1:М, то можно, как в случае связи М:М, использовать отдельную связующую таблицу, но ключом связующей таблицы будет уже только идентификатор объекта.

Однако если между объектами предметной области имеется связь 1:М и класс принадлежности n-связной сущности является обяза­тельным, то можно использовать только два отношения (по одному для каждой сущности). В отношение, соответствующее сущности, к которой идет единичная связь, нужно дополни­тельно добавить идентификатор связанного с ней объекта.

Отображение связи типа 1:1. Если связь между объектами 1:1 и класс принадлежнос­ти обеих сущностей является обязательным, для отображения обоих объектов и связи между ними можно использовать одну таблицу. Но если класс принад­лежности каждого из них является необязательным, то следует использовать три отношения: по одному для каждой сущности и одно – для отображения связи между ними.

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

Отображение сложных объектов

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

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

Отображение обобщенных объектов. При этом могут быть при­няты разные решения.

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

Другим вариантом является решение, при котором каж­дой категории объектов нижнего уровня ставится в соответствие от­дельное отношение. В этом случае каждое отношение будет включать в себя идентификатор объекта (если иден­тификаторов несколько, то в каждое из отношений будут включены все они), свойства, присущие родовым объектам, а также свойства, присущие данному подвиду объектов. Свойство, по которому прово­дится разбиение класса на подклассы, в этом случае в качестве поля не включается ни в одно из отношений.

Кроме этих двух решений возможны и комбинирован­ные варианты.

Отображение составных объектов. В случае отношения объектов типа М:М, для отображения связи «целое-часть» можно воспользоваться двумя файлами базы дан­ных. Первый из них будет хранить информацию о самих объектах, а второй – информацию о связи между ними, а также дополнительную информацию, характеризующую эту связь. В случае отношения объектов типа 1:М, для отображения можно использовать соответствующую модель.

Дополнительные рекомендации по проектированию БД

Реляционная база данных, полученная в результате использова­ния предложенного выше алгоритма проектирования, является нор­мализованной и автоматически находится в четвертой нормальной форме (4 НФ). Нормализация выполняется пу­тем вертикального разбиения (проекции) исходного отношения. Только учтите, что 4НФ нам Акопов не объяснял. Если что – ссылаться на 3НФ – прим.ред.

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

 

21)  Критерии оценки БД

1. Адекватность – соответствие базы данных реальной предмет­ной области.

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

3. Адаптируемость.

3.1. Адаптируемость к изменениям в предметной области.

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

3.1.2. Простота и эффективность внесения изменений.

3.1.2.1. Простота корректировки структуры БД данных.

3.1.2.2. Простота и трудоемкость корректировки значений дан­ных.

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

3.3. Адаптация к изменениям используемых программных и тех­нических средств.

Одним из проявлений рассматриваемого свойства является мас­штабируемость.

4. Универсальность.

5. Сложность структуры БД.

6. Степень дублирования данных в БД.

7. Сложность последующей обработки.

8. Объем требуемой памяти.

9. Скорость (время) обработки информации (время реакции на запрос).

 

22) Создание файлов баз данных/таблиц в реляционных системах.

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

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

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

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

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

Многие СУБД предоставляют возможность использовать и иные способы создания таблиц, не предполагающие непосредственного описания каждого поля проектировщиком.

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

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

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

23) Возможности совместной обработки файлов в реляционных СУБД.

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

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

Существует несколько способов совместного использования дан­ных в многопользовательской среде.

  1. 1. Совместное использование всей базы данных.
  2. 2. Совместное использование таблиц базы данных.
  3. 3. Совместное использование объектов базы данных или страниц доступа к данным в Интернете.
  4. 4. Репликация базы данных.
  5. 5. Создание приложения в архитектуре «клиент-сервер».

Различие в первых двух возможностях обусловлено особенностя­ми архитектуры Access и является специфичным именно для этой СУБД.

Можно поместить всю базу данных Access на сетевой сервер или в общую папку. Далее следует убедиться, что для базы данных задано открытие в ре­жиме совместного доступа. Этот режим используется по умолчанию. Чтобы установить этот режим, необходимо в меню Сервис выбрать команду Параметры, затем на вкладке Другие в группе параметров Режим открытия по умолчанию выбрать параметр общий доступ (рис. 10.8).

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

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

 

 

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

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

Преимущества использования присоединения:

  • доступ к БД осуществляется быстрее, поскольку отсутствуют траты времени на передачу объектов по сети;
  • резервирование данных и обновление других объектов упро­щается, если таблицы хранятся отдельно от остальных объек­тов БД;
  • пользователь может менять свои формы и отчеты, не оказы­вая влияние на компоненты, разработанные другими пользовате­лями.

Присоединенные таблицы могут находиться не только в другой БД Access, но даже в БД других СУБД.

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

Существуют различные способы выполнения репликации и син­хронизации баз данных в Access:

  • портфельная репликация;
  • команды репликации в меню Сервис Microsoft Access;
  • репликация в проекте Microsoft Access;
  • программная репликация;
  • диспетчер репликации Microsoft.

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

При работе в среде «клиент-сервер» можно использовать име­ющиеся дополнительные возможности и способы защиты, обес­печиваемые сервером. Данные сохраняются в таблицах на сервере базы данных, например на Microsoft SQL Server, а не в локальных таблицах в Microsoft Access. При открытии файла базы данных Access (.mdb) в режиме об­щего доступа Microsoft Access создает файл сведений о блокировке (.ldb) с тем же именем  и в той же папке, что и файл базы данных. В файле сведений о блокировке сохраня­ются имя компьютера и имена всех совместно работающих пользо­вателей базы данных в системе защиты. Microsoft Access использу­ет эти сведения для управления совместной работой.

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

Microsoft Access позволяет отслеживать состояние записей во вре­мя внесения в них изменений и обеспечить использование самых све­жих данных. Если два (или более) пользователя пытаются внести из­менения в одну и ту же запись, на экране появляется сообщение, по­могающее разрешить конфликт. Чтобы облегчить отслеживание состояния записей, Microsoft Access отображает специальные маркеры в области выделения теку­щей записи, которые позволяют понять, в каком состоянии находится запись.

Реплицирование может применяться не только при работе несколь­ких пользователей в сети, но и, например, при использовании как на­стольного, так и переносного компьютера. При этом на переносном компьютере создается «оторванная» реплика, с которой можно рабо­тать автономно. Впоследствии, в слу­чае необходимости (если в реплику вносились изменения, которые должны быть учтены в основной базе данных) можно произвести син­хронизацию.

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

 

24) Возможности задания ограничений целостности в современных СУБД.

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

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

  1. Спецификация уникальности: – ) требует, чтобы никакие две строки в таблице не имели оди­наковых значений в указанном столбце или совокупности столбцов.
  • определение первичного ключа;
  • задание признака уникальности поля/совокупности полей.
  1. Ограничение на столбец:
  • ограничение на неопределенное значение;
  • задание проверочных ограничений на строки таблицы (ограни­чения контроля).
  1. Определение ограничений целостности связей (ссылки междутаблицами);

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

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

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

Триггеры не определены в стандарте SQL, но поддерживаются практически во всех SQL-серверах и даже во многих настольных СУБД

 

25)Ограничения целостности. Понятие и классификация.

 

7.  Целостность БД.
Понятие целостности.
Целостность – актуальность и непротиворечивость информации в БД в любой момент времени, а также ее защищенность от разрушения и несанкционированного изменения.

Целостность – один из аспектов информационной безопасности, наряду с доступностью и конфиденциальностью.

Целостность – неотъемлемое свойство БД, Обеспечение целостности – важнейшая задача проектирования БД.

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

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

Классификация ограничений целостности.
На основе принадлежности к информационным объектам
Поле, атрибут Тип и формат допустимые для данного поля символы, а иногда и более жесткие ограничения на допустимые значения (как, например, для полей типа дата или логическое)
Диапазон значений односторонние и двусторонние, открытые и закрыты (Односторонний – всегда открытый, двусторонний – открытый или закрытый. Пример открытого двустороннего: <6 and >50)
Признак непустого поля. обязательность для заполнения)
Задание домена множество возможных значений. Пример: п
Признак уникальности поля ограничением целостности объекта (сущности).
Функциональные зависимости Если БД с находится в 4НФ, то, определяя ключи и вероятные ключи отношений, тем самым определяются и функциональные зависимости между атрибутами. (информация о функц. зависимостях берется из инфологической модели)
Запись, строка, кортеж соотношения значений отдельных полей в пределах одной строки. Пример: «СТАЖ» не должен превышать [«ВОЗРАСТ» – 16]
Таблица, отношение, файл соотношения строк внутри таблицы: уникальность поля, ограничения на средние значения, цикличность: например, нельзя быть родителем и ребенком одного и того же человека;
Совокупность связных таблиц Ограничение целостности связи значение атрибута, отражающего связь между объектами и являющегося внешним ключом отношения, обязательно должно совпадать с одним из значений атрибута, являющегося ключом отношения, описывающего соответствующий объект.
Ограничение по существованию заключающееся в том, что для существования объекта в отношении S1 необходимо, чтобы он был связан с объектом в отношении S2
Другие проверки логических связей между таблицами
Алгоритмические зависимости,Запрет на обновление
Целостности банка данных 

 

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

По режиму проверки корректности БД

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

Более предпочтительный способ описания по сравнению с процедурным.

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

 

26) Ограничения целостности связи. Понятие. Возможности реализации в современных СУБД.

Контроль целостности связей Из перечисленных видов связи наиболее широко используется связь вида 1:М. Связь вида 1:1 можно считать частным случаем связи 1:М, когда одной записи главной таблицы соответствует одна запись вспомогательной таблицы. Связь М:1 по сути, является «зеркальным отображением» связи 1:М. Оставшийся вид связи М:М характеризуется как слабый вид связи или даже как отсутствие связи. Поэтому в дальнейшем рассматривается связь вида 1:М.

При образовании связи вида 1:М одна запись главной таблицы (главная, родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи).

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

  • каждой записи основной таблицы соответствует нуль или более записей дополнительной таблицы;
  • каждая запись дополнительной таблицы имеет ровно одну родительскую запись основной таблицы.

Контроль целостности осуществляется при выполнении следующих основных операций над данными двух таблиц:

  • ввод новых записей,
  • модификацию записей,
  • удаление записей.

При вводе данных новых записей возникает вопрос определения такой последовательности ввода записей в таблицы, чтобы не допустить нарушение целостности. Исходя из приведенных правил, логичной является схема, при которой данные сначала вводятся в основную таблицу, а потом — в дополнительную. При этом контроль целостности может заключаться как в запрете выполнения нарушающих целостность действий (режим запрета добавления записи в дочернюю таблицу, если нет соответствующей записи в родительской), так и на обновление связанных записей с целью сделать корректным изменение данных (обработка обновления – исправление значения внешнего ключа во всех дочерних записях при изменении значения первичного ключа в родительской записи).   + рассказать про Ервин. Relationship Editor.

 

27) Языки запросов. Общая характеристика.

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

Выделяют следующие разновидности языков реляционной алгебры:

  • dBASe-подобные языки приближены к языкам структурного программирования, обеспечивают создание интерфейса пользователя и типовые операции обработки; – СУБД реляционного типа, такие, как dBASe, Paradox, FoxPro, Clipper, Rbase и др., используют языки манипулирования данными, обеспечивающие основные операции обработки реляционных баз данных, образующих класс dBASE-подобных (X-Base).
  • графические реляционные языки, которые ориентированы на конечных пользователей; – Типичным представителем является язык QBE(Query By Example), реализованный в среде электронных таблиц, в ряде СУБД, в пакете Microsoft Query.

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

  • SQL-подобные языки запросов, реализованные а большинстве многопользовательских и распределенных систем управления базами данных.

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

 

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

– реляционная алгебра;

– реляционное исчисление.

 

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

 

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

 

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

 

28) Язык QBE. Общая характеристика.

QBE (Query by example) — способ создания запросов к базе данных, с использованием образцов в виде текстовой строки, названия документа или списка документов. Система QBE преобразует пользовательский ввод в формальный запрос к базе данных, что позволяет пользователю делать сложные запросы без необходимости изучать более сложные языки запросов таких как SQL. Этот метод отбора данных впервые предложен компанией IBM в 1970 г.

В современных СУБД широко используются табличные языки запросов. Наиболее распространенным среди них является язык QBE. Язык QBE предназначен для работы в интерактивном режиме и ориентирован на конечного пользователя. Язык QBE реализован во многих современных СУБД, например dBase IV, Paradox, ОФИС-ИНФО и др. Конкретные реализации этого языка несколько отличаются друг от друга, но все они построены по единому принципу. Суть подхода, воплощенного в языке QBE, заключается в следующем.

Запрос формируется в режиме диалога путем заполнения таблицы специального вида. QBE-технология дает пользователю визуальное представление достаточно сложного запроса.

Преимуществом поиска QBE является то, что для формирования запроса не требуется изучать язык запросов. Когда вы инициируете поиск, на экран выводится окно, в котором указаны все поля данных, встречающиеся в каждой записи данных; введите информацию, которая ограничивает поиск только указанными критериями: те поля, которые не будут заполнены, могут соответствовать чему угодно. На экране дисплея высвечивается «скелет» (образ, форма, структура) одной или нескольких таблиц (файлов баз данных, отношений), данные из которых будут участвовать в запросе. «Скелет» выбранной пользователем таблицы выводится на экран дисплея в виде «шапки», в крайнем левом столбце которой записано название файла базы данных, а в остальных — имена полей файла. В этой форме пользователь определяет условия запроса. Например, если пользователю необходимо получить все записи с заданным значением определенного атрибута, то в соответствующем столбце «скелета» указывается это значение.

 

29) QBE. Формирование “скелета ответа”. Возможности упорядочения ответа.

 

Наиболее распространенным среди табличных языков запросов является язык QBE (Query-By-Example — запрос по примеру). Конкретные реализации этого языка несколько отличаются друг от друга, но все они построены по единому принципу. Суть подхода, воплощенного в языке QBE, заключается в следующем.

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

Во второй форме (“скелете” запроса табличной формы) пользователь задаёт условия запроса: какие поля участвуют в формировании запроса, условия отбора и т.д. Например, если пользователю необходимо получить все записи с заданным значением определенного атрибута, то в соответствующем столбце «скелета» указывается это значение.

id name Lastname
Иван

Этот запрос вернет всех Иванов – прим. ред.

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

 

30) QBE. Особенности обработки полей разных типов. Работа с вычисляемыми полями. Использование агрегирующих функций.

 

Как известно, в большинстве СУБД при вводе в выражение зна­чений того или иного типа используются соответствующие данному типу данных ограничители. В Access при задании запроса ограничи­тели можно не ставить. В зависимости от типа поля, которое вводит­ся в выражение, определяющее условие отбора, ограничители добав­ляются системой автоматически: прямые кавычки (” “) вокруг строко­вых значений; символы (#) вокруг дат.

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

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

Агрегирующие показатели могут быть включены не только в “Запросы”, но и в “Отчёты”. Возможности включения агрегирующих показателей в запросы и отчёты различаются между собой. Результатом запроса всегда является плоская таблица. Поэтому в запросах могут быть получены только одноуровневые итоги. В отчётах же может быть получено несколько степеней итогов.

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

  • Сумма
  • Минимум
  • Максимум
  • Среднее
  • Подсчёт

Некоторые системы включают дополнительные статистические функции, такие, как стандартное отклонение, дисперсия, и т.д.

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

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

 

31) Совместная обработка файлов в QBE.

 

В некоторых зап­росах могут потребоваться данные из нескольких таблиц. Например, в базе данных, кроме таблицы KADR, имеется таблица «Выработка» (VRBT) с полями:

  • TABN – табельный номер;
  • DAT – дата;
  • KODDET – код детали;
  • KOLV – количество.

В запросе «Выдать информацию о выработке рабочего Евгения Петрова» необходима совместная обработка таблиц VRBT и KADR, так как в таблице «Выработка» нет сведений о фамилиях и именах рабочих.

«Скелеты» всех таблиц, которые нужны для реализации запроса (в нашем примере – двух таблиц), должны быть вызваны на экран.

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

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

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

Существуют и другие способы установления связей.

Теоретически возможны разные типы соединений таблиц. Наи­более распространенным является соединение, при котором в резуль­татную таблицу помещаются те соединенные записи, для которых значение поля связи основной таблицы совпадает с соответствующим полем в зависимой таблице. В описанных выше случаях устанавли­вается именно такое соединение. В настоящее время широко исполь­зуются такие понятия, как «левое» и «правое» соединение, когда в результатную таблицу помещаются все записи из основной или зави­симой таблицы соответственно, даже если для них нет связанных за­писей в другой таблице. Но не все системы позволяют в QBE реализовывать такие соединения. В случаях, когда возможно задание раз­ных типов соединений, конкретный способ реализации отличается в разных СУБД. Так, в Access «левое» и «правое» соединения можно определить, задав для связи «параметры объединения» или перейдя в SQL. В dBase IV никаких специфических терминов для обозначения такого типа соединений нет, но включение слова Every в запрос на QBE выполняет ту же роль.

Работа с несколькими таблицами в конкретных СУБД различает­ся не только тем, каким способом можно определить связь между таб­лицами. Так, например, некоторые системы обязывают пользователя связать те таблицы/файлы, которые указываются как исходные для запроса; другие автоматически связывают открытые файлы по тем полям, которые система воспринимает как поля связи (чаще всего это поля, имеющие одинаковые имена, тип и длину); третьи – оставляют эти таблицы изолированными, если пользователь не указал, как они должны быть связаны, четвертые – выполняют декартово произведе­ние открытых таблиц. Например, в dBase IV вызвать несколько фай­лов БД на панель запросов и не связать их было нельзя. В MS Query, Access если таблицы не связаны, то при выполнении запроса это при­водит к связыванию каждой записи одной таблицы с каждой записью другой.

 

32) Реализация запросов со сложными условиями в QBE.

 

Допускается задание не только простых, но и сложных запросов, компоненты которых связаны операторами AND (и) или OR (или). Операторы AND и OR в явном виде не указываются при формулировании запроса. При отображении запросов на экране используется следующее правило: если в сложном запросе его компоненты представляют разные атрибуты и должны быть связаны оператором AND, то они записываются в одной строке (рис. 6.2). Если компоненты запроса должны быть связаны операторами OR, то они записываются на разных строках (рис. 6.3).

На рис. 6.2 изображен запрос «Выдать информацию о сотруднике с фамилией Диго и именем Светлана», а на рис. 6.3 — «Выдать информацию о сотрудниках, имеющих фамилию Диго или имя Светлана» (т. е. о всех сотрудниках, которые имеют фамилию Диго, и всех сотрудниках, имеющих имя Светлана).

 

33) QBE. Корректировка данных.

 

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

К корректирующим запросам относят­ся запросы на обновление (Update) и на удаление (Delete) записей, а также добавление (Append, Insert) записей из одной таблицы или нескольких связанных таблиц в конец другой таблицы. В документа­ции по Access к типу «запросов на изменение» отнесены не только перечисленные выше запросы, но еще и «запрос на создание табли­цы». Последний запрос все-таки отличается от названных ранее: пер­вый круг запросов меняет содержание существующих таблиц, а после­дний – создает новую таблицу, т.е. фактически меняет имеющуюся структуру базы данных. Поэтому «запрос на создание таблицы» вы­делен в отдельную группу.

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

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

Запрос на обновление. Для создания запроса на обновление не­обходимо сначала выбрать таблицу(ы), поля которой будут корректироваться, а затем изменить тип запроса. При этом вид бланка запроса изменится по срав­нению с запросом на выборку: в бланке отсутствуют строки «Сорти­ровка» и «Вывод на экран», но зато появилась строка «Обновление». В бланк запроса включаются те поля, значения которых будут изменяться. В строке «Обновление» соответствующего поля записывается его новое значение или выражение для его вычисления. Если обновление касается не всех записей таблицы, а только некоторых из них, то нужно обычным образом задать условия отбора. С целью убедиться, что усло­вия отбора заданы верно, рекомендуется сначала посмотреть результа­ты отбора. Это можно сделать двумя способами:

  1. просмотреть запрос в режиме таблицы;
  2. выполнить запрос как запрос на выборку.

«Открытие» запроса на обновление означает изменение значений в базе данных. Каждое «Открытие» запроса на обновление будет оз­начать обновление уже обновленных данных.

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

Если в запросе на удаление не указать условие отбора, то будут удалены все записи. В некоторых случаях зап­рос-удаление приводит к удалению записей в таблицах, не вклю­ченных в запрос. Это случается, если в запрос включена таб­лица, находящаяся на стороне «один» отношения «один ко многим», а целостность данных обеспечивается параметром «Каскадное удаление». При удалении записей из этой таблицы будут также удалены связанные записи из таблицы, находящейся на стороне «многие».

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

Таблица, в которую осуществляется добавление, может быть как в той же базе данных, так и в другой, причем это не обязательно дол­жна быть база данных Access (это может быть Microsoft FoxPro, Paradox или dBASE, а также база данных SQL).

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

Если все поля таблицы-источника должны быть перенесены в целевую таблицу и поля в таблице-источнике и целевой таблице име­ют одинаковые имена, то можно просто переместить символ «звездочка» (*) в бланк запроса. Однако при работе с репли­кой базы данных добавлять придется все поля. Кроме того, при ис­пользовании символа «звездочка» (*), даже если структуры обеих таб­лиц полностью совпадают, могут возникнуть проблемы с ключами (если ключевое поле имеет тип «Счетчик», то для автоматического добавления значений счетчика не следует при создании запроса пе­ремещать поле счетчика в бланк запроса).

Если в обеих таблицах выделенные поля имеют одинаковые име­на, соответствующие имена автоматически вводятся в строку «До­бавление». Если имена полей двух таблиц отличаются друг от друга, в строку «Добавление» необходимо ввести имя поля целевой табли­цы, которое соответствует полю таблицы-источника.

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

 

34) Язык SQL. Общая характеристика.

 

Одним из самых распространенных языков запросов является язык SQL (Structure Query Language). Он был разработан в середине 1970-х гг. (IBM). Первой коммерческой системой, в которой реализо­ван этот язык, была система Oracle (1979 г.). В дальнейшем он был реализован в целом ряде популярных СУБД для различных типов ЭВМ и операционных систем. В некоторых СУБД, таких, как Oracle, INGRES, MS SQL-сервер и др., язык SQL используется в качестве основного. В других системах, например СУБД семейства dBase, Access, AD ABAS и других, этот язык применяется в качестве альтер­нативного.

Предшественником SQL был язык SEQUEL (Structured English Query Language).

По сути это не предшественник, а более ранняя редакция с более длинным названием. Название часто используется и сейчас – прим. ред.

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

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

Однако, существуют процедурные расширения языка, где такие конструкции есть. К примеру, PL/SQL (Procedural Language/…) – прим.ред.

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

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

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

Язык баз данных SQL включает в себя два языка: язык определе­ния схемы (SQL-DDL) я язык манипулирования данными (SQL-DML). Язык DDL позволяет описывать и создавать такие объекты базы дан­ных, как таблицы, индексы, представления и др. Язык DML дает воз­можность задавать поисковые и корректирующие запросы к базе дан­ных. Операторы языка манипулирования данными SQL могут исполь­зоваться как самостоятельно (интерактивный или автономный SQL), так и совместно с операторами других языков манипулирования дан­ными (встроенный SQL).

Кроме DDL и DML иногда в качестве самостоятельного подмно­жества выделяют язык управления данными (DCL – Data Control Language). Операторы DCL обычно используются для создания объек­тов, относящихся к управлению доступом пользователей к базе дан­ных, а также для назначения пользователям подходящих уровней при­вилегий доступа.

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

SQL является языком высокого уровня. Пользователь не должен при его использовании помнить об открытии и закрытии каких-либо таблиц, определять наиболее эффективный способ реализации зап­роса, активизировать индексы и т.п. Все это система делает автоматически. Во многих современных СУБД имеются построители запро­сов SQL. Обычно в этом качестве выступают языки типа QBE. Но не все типы запросов SQL могут быть реализованы на QBE. Некоторые типы запросов, например запрос-объединение (Union), невозможно создать на QBE.

 

35) Стандарты SQL.

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

Язык SQL имеет официальный стандарт – ANSI/ISO. Большинство разработчиков придерживаются этого стандарта,  однако часто расширяют его для реализации новых возможностей обработки данных.

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

Неполнота стандарта SQL-89 привела к появлению в 1992г. следующей версии языка SQL. SQL-92 охватывает практически все необходимые проблемы: манипулирование схемой базы данных, управление транзакциями и сессиями, динамический SQL. В стандарте существуют три уровня: базовый, промежуточный и полный. Только в последнее время СУБД ведущих производителей обеспечивается совместимость с полным вариантом языка.

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

36.Общая структура команды Select языка SQL.

 

Общая характеристика оператора. Для отбора информации из базы данных служит оператор SELECT. Синтаксис оператора выгля­дит следующим образом:

SELECT [DISTINCT]

{{функция агрегирования.. | выражение для вычисления значения

[AS имя столбца]}.,}

| {спецификатор.*}

|*

FROM {{имя таблицы [А8][имя корреляции].[(имя столбца.,..)]}

|{подзапрос [АS][имя корреляции.[имя столбца.,..]}

|соединенная таблица}.,..

[WHERE предикат ] [GROUP BY {{[ имя таблицы| имя корреляции]}.] имя столбца}.,..}] [HAVING предикат] [UNION | INTERSECT | EXCEPT}[ALL] [CORRESPONDING [BY (имя столбца.,..)]]

оператор select | TABLE имя таблицы | конструктор значений таб­лицы] [ORDER ВY{{столбец-результат [ASC| DESC]}.,..}

|{{положительное 4hoio[ASC| DESC]}.,..}]};

Оператор состоит из предложений SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, которые должны быть записаны в команде именно в той последовательности, в которой они перечисле­ны в синтаксической формуле.

Предикаты:

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

DISTINKT – исключает из результатной таблицы повторяющиеся строки

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

TOP – позволяет возвращать определенное число записей из общего числа, получающегося при отбре.

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

 

•          COUNT – подсчет;

•          SUM – сумма;

•          МАХ -максимум;

•          MIN – минимум;

•          AVG – среднее

 

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

Таблицы имеют тенденцию становиться очень большими, поскольку с течением времени, все большее и большее количество строк в нее добавляется. Поскольку обычно из них только определенные строки интересуют вас в данное врем, SQL дает возможность вам устанавливать критерии чтобы определить какие строки будут выбраны для вывода. WHERE – предложение команды SELECT, которое позволяет вам устанавливать предикаты, условие которых может быть или верным или неверным для любой строки таблицы. Команда извлекает только те строки из таблицы для которой такое утверждение верно. Например, предположим вы хотите видеть имена и комиссионные всех продавцов в Лондоне. Вы можете ввести такую команду:

 

SELECT sname, city

FROM Salespeople;

WHERE city = “LONDON”;

 

Когда предложение WHERE представлено, программа базы данных просматривает всю таблицу по одной строке и исследует каждую строку чтобы определить верно ли утверждение. Следовательно, для записи Peel, программа рассмотрит текущее значение столбца city, определит что оно равно “London”, и включит эту строку в вывод.

Предложение GROUP BY позволяет группировать записи по одному полю или совокупности полей. Обычно используется вместе со статистическими функциями, позволяющими проводить вычисления для сформированных групп. В оператор SELECT содержащий предложение GROUP BY могут быть включены как предложение WHERE так и предложение HAVING. WHERE используется для исключения записей из группировки, а HAVING для применения фильтра к записям после группировки.

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

Order By поле_1[ASC/DESC]

ASC/DESC – по возрастанию или по убыванию.

37. Вложенные запросы в SQL.

Язык SQL позволяет строить вложенные запросы, т.е. такие запросы, которые в условиях используют результаты работы другого запроса. Например, нам известна фамилия продавца (пусть это «Курочкин»), но не известен его номер, а нам необходимо знать все заказы этого продавца. Этот запрос можно выполнить в два этапа:

– сначала найти по таблице Salespeople код продавца (выполнив запрос: SELECT snum FROM Salespeople WHERE sname = “Курочкин”);

– затем, по коду продавца (код продавца с фамилией «Курочкин» равен ‘0001’) выбрать из таблицы Orders все его заказы (выполнив запрос: SELECT * FROM Orders WHERE snum=’0001’).

 

Такой способ получения результата не очень удобный. Добиться аналогичного результата можно другим способом – построением вложенного запроса. Для этого в Конструкторе в строке «Условия запроса» введем запрос на поиск кода продавца. На рис.39. показано как выглядит вложенный запрос в Конструкторе.

Текст SQL-запроса с вложенным запросом показан ниже:

SELECT *

FROM Orders

WHERE snum=(SELECT snum FROM Salespeople WHERE sname = “Курочкин”)

Важным условием корректности исполнения вложенных запросов, является однозначность результата «внутреннего» (вложенного) запроса.  В нашем случае мы имеем однозначный результат внутреннего запроса ( код продавца «Курочкина» равен ‘0001’).

Более сложный вложенный запрос, построенный на основании предыдущего запроса, может выглядеть так:

SELECT orders.onum as НОМЕР, orders.odate as ДАТА, Salespeople.sname as ФАМИЛИЯ,

price.pname as МАРКА, orders.amount as ЦЕНА

FROM Salespeople INNER JOIN (price INNER JOIN orders ON

price.pnum = orders.pnun) ON Salespeople.snum = orders.snum

WHERE Salespeople.snum =(SELECT snum FROM Salespeople                                         WHERE sname = “Курочкин”);

Корректировка данных в SQL.

 

Изменение:

 

Изменение значений данных в полях производится с помощью команды UPDATE, которая имеет следующую конструкцию:

 

UPDATE <имя таблицы>

SET <имя столбца 1>=<значение>,

<имя столбца 2>=<значение>,…,

<имя столбца N>=<значение>,

WHERE <условие>

 

Запрос на изменение в Access  удобно строить с помощью конструктора в два этапа. Сначала построить простой запрос с условием для отбора строк. Посмотреть результаты отбора и, если, отобранные строки полностью удовлетворяют вашим условиям, трансформировать исходный запрос на запрос в команду UPDATE.

Предположим, необходимо всем покупателям, которые живут в городе «Москва», изменить рейтинг на 125. Выполним запрос на отбор строк с покупателями, которые живут в городе «Москва»:

 

SELECT * FROM Customers WHERE caddress = “Москва”;

 

В результате отберутся только две строчки. Теперь выполним команду Запрос-Обновление и снова войдем в режим просмотра SQL-запросов. Запрос на обновление будет выглядеть, как показано ниже:

 

UPDATE Customers SET

WHERE (((Customers.caddress) = “Москва”));

 

В оператор SET добавим имя столбца и новое значение и получим полный запрос на обновление содержимого столбца raiting:

 

UPDATE Customers SET

raiting=125

WHERE (((Customers.caddress)=”Москва”));

 

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

 

Удаление:

 

аналогичным образом строятся и запросы на удаление записей из таблицы. Общая форма запроса на удаления имеет вид:

 

DELETE *

FROM <имя таблицы>

WHERE <условия отбора записей>

 

Напишем запрос на удаление всех продавцов, которые живут в городе «Тула». Для этого сначала запишем запрос, который отбирает все записи с продавцами, у которых выполняется условие saddress =”Тула”:

 

SELECT * FROM Salespeople WHERE saddress =”Тула” ;

 

В результате выберутся только две строки. Теперь войдем в режим конструктов запросов и выберем команду Запрос-Удаление. Запрос на отбор строк трансформируется в запрос на удаление и примет вид:

 

DELETE Salespeople.saddress, *

FROM Salespeople

WHERE (((Salespeople.saddress)=”Тула”));

 

После выполнения запроса ранее отобранные две строки будут удалены из таблицы Salespeople.

Добавление:

Рассмотрим команду вставки  данных  в таблицы:

INSERT INTO <имя таблицы> VALUES (<значение 1>,< значение 2>,…,< значение N>);

Пример вставки новой записи с данными. Например, надо добавить нового продавца (в таблицу Salespeople) со следующими параметрами: код продавца – 1010, фамилия – Бояринов, адрес – Москва, комиссионные – 0.12, телефона – нет, почта –  bojar @yandex.ru. Это можно сделать следующим запросом:

INSERT INTO Salespeople

VALUES (“1010”, “Бояринов”, “Москва”, 0.12, Null, “bojar@yandex.ru”);

В некоторых случаях можно использовать имена столбцов для ввода данных в конкретные поля. Например, если нам надо ввести нового покупателя под номером «2007», о котором известна пока только его фамилия (“Синичкин”), а другие данные пока еще неизвестны. Тогда для этого можно использовать следующую команду:

 

INSERT INTO Customers (cname, cnum)

VALUES (“Синичкин”, “2007”);

 

В результате выполнения запроса в таблицу покупателей добавится новая строка с кодом «2007» (cnum =”2007″), у которой будет заполнен только столбец cname (cname=”Синичкин”).

Можно осуществить вставку данных в текущую таблицу, путем выбора данных по запросу из другой таблицы. Например, создадим новую таблицу таблицу «Жители Москвы» (“CitizenOfMoscow”), в которую мы хотим скопировать всех покупателей, живущих в городе «Москва». Для переноса данных в эту таблицу можно записать и выполнить запрос следующего вида:

 

INSERT INTO CitizenOfMoscow

SELECT * FROM Customers WHERE city=”Москва”;

 

Корректное выполнение этого запроса предполагает, что таблица CitizenOfMoscow создана до начала его выполнения и структура таблицы CitizenOfMoscow совпадает со структурой таблицы Customers.

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

 

ALERT TABLE < имя таблицы > ADD <тип данных><размер>.

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

 

Команда ALTER не является стандартной для ANSI, поэтому на практике в Access ее приходится заменять набором команд. Так, например, набор команд на обновление структуры таблицы может состоять из следующих команд: создание новой временной таблицы (CREATE),  в которую осуществляется перенос данных в новую таблицу (INSERT совместно с SELECT) и удаление старой таблицы (DROP). Затем создается новая таблица под старым именем и в нее переносится данные из временной таблицы. В конце операции временная таблица удаляется.

 

38. SQL. Создание объектов.

 

 

Команды определения таблиц относятся к разделу языка SQL, который принято называть языком DDL (Data Definition Language), который позволяет реализовать процедуры создания объектов реляционной базы данных.

Операторы языка DDL

Вид Название Назначение
DDL CREATE TABLE создание таблицы
DROP TABLE удаление таблицы
ALTER TABLE изменение структуры таблицы
CREATE INDEX создание индекса
DROP INDEX удаление индекса

Инструкция CREATE TABLE .

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

Синтаксис :

CREATE [ TEMPORARY ] TABLE таблица ( поле _1 тип [( размер )] [ NOT NULL ] [индекс_1] [, поле_2 тип [(размер)] [ NOT NULL ] [индекс_2] [, …]] [,составной_индекс [, …]])

Аргументы инструкции CREATE TABLE :

таблица – имя создаваемой таблицы;

поле_1, поле_2 – имена одного или нескольких полей, создаваемых в новой таблице. Таблица должна содержать хотя бы одно поле;

тип – тип данных поля в новой таблице;

размер – размер поля в знаках (только для текстовых и двоичных полей);

индекс_1, индекс_2 – предложение CONSTRAINT , предназначенное для создания простого индекса;

составной_индекс – предложение CONSTRAINT , предназначенное для создания составного индекса.

Дополнительные сведения:

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

NOT NULL – значение поля не должно быть пустым;

UNIQUE – значение поля должно быть уникальным;

PRIMERY KEY – определяет принадлежность поля ключу;

DEFAULT – автоматическая подстановка конкретного значения;

CHECK (<условие>) – проверка условия, которому должен удовлетворять вводимое значения в поле.

Удаление таблиц выполняется с помощью команды DROP TABLE <имя таблицы>

Например: Удалить таблицу Employees

DROP TABLE Employees

Синтаксис команды создания индекса можно представить так:

CREATE INDEX <имя индекса> ON <имя таблицы> (<имя столбца 1> [,<имя столбца 2>] …);

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

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

DROP INDEX <имя индекса>.

Изменить структуру созданной  таблицы можно с помощью команд

– ALTER TABLE – изменить таблицу;

– DROP COLUMN – удалить столбец;

– ALTER COLUMN – изменить параметры столбца;

– RENAME COLUMN – переименовать столбец;

Пример добавления столбца NewPrice в таблицу Price:

ALTER TABLE Price ADD COLUMN NewPrice FLOAT

Удалить столбец NewPrice из таблицы Price:

ALTER TABLE Price DROP COLUMN NewPrice

40) SQL. Встроенный JOIN + 41. Чем отличаются внутренние соединения (INNER

JOIN) от внешних (LEFT JOIN или RIGHT JOIN)?

 

JOIN – оператор языка SQL, позволяющий включить данные из нескольких таблиц. Входит в оператор FROM и отдельно от него не используется.

Различные SQL JOINs

Прежде чем приводить примеры, мы перечислим типы JOIN доступные к использованию и различия между ними.

  • JOIN: Возвращает строки, когда есть хотя бы одно совпадение в обеих таблицах.
  • LEFT JOIN: возвращает все записи первой таблицы списка и те записи правой таблицы, которые совпадают с с записями левой таблицы по объединяющему столбцу. LEFT JOIN удобно применять тогда, когда требуется получить все записи главной таблицы и соответствующие им записи зависимой таблицы.
  • RIGHT JOIN: Работает аналогично, только по правой таблице.
  • FULL JOIN: Возвращает строки, когда есть хоть одно совпадение в любой из таблиц.

Для пояснений будут использоваться следующие таблицы:

Люди, проживающие в городах (таблица Person)

Name CityId
Андрей 1
Леонид 2
Сергей 1
Григорий 4

Города (таблица City)

Id Name
1 Москва
2 Санкт-Петербург
3 Казань

INNER JOIN

Объединяет две таблицы, где каждая строка обеих таблиц в точности соответствует условию. Если для строки одной таблицы не найдено соответствия в другой таблице, строка не включается в набор.

SELECT *

FROM Person

INNER JOIN City ON Person.CityId = City.Id

Person.Name Person.CityId City.Id City.Name
Андрей 1 1 Москва
Леонид 2 2 Санкт-Петербург
Сергей 1 1 Москва

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

 

LEFT JOIN

К левой таблице присоединяются все записи из правой, соответствующие условию (по правилам inner join), плюс все не вошедшие записи из левой таблицы, поля правой таблицы заполняются значениями NULL.

SELECT *

FROM Person

LEFT OUTER JOIN City ON Person.CityId = City.Id

Person.Name Person.CityId City.Id City.Name
Андрей 1 1 Москва
Леонид 2 2 Санкт-Петербург
Сергей 1 1 Москва
Григорий 4 NULL NULL

RIGHT JOIN

Аналогично left outer join, но применяется для правой таблицы.

К левой таблице присоединяются все записи из правой, соответствующие условию (по правилам inner join), плюс все не вошедшие записи из правой таблицы, поля левой таблицы заполняются значениями NULL.

SELECT *

FROM Person

RIGHT OUTER JOIN City ON Person.CityId = City.Id

Person.Name Person.CityId City.Id City.Name
Андрей 1 1 Москва
Леонид 2 2 Санкт-Петербург
Сергей 1 1 Москва
NULL NULL 3 Казань

FULL JOIN

К левой таблице присоединяются все записи из правой, соответствующие условию (по правилам inner join), плюс все не вошедшие записи из правой таблицы, поля левой таблицы заполняются значениями NULL и плюс все не вошедшие записи из левой таблицы, поля правой таблицы заполняются значениями NULL

SELECT *

FROM Person

FULL OUTER JOIN City ON Person.CityId = City.Id

Person.Name Person.CityId City.Id City.Name
Андрей 1 1 Москва
Леонид 2 2 Санкт-Петербург
Сергей 1 1 Москва
Григорий 4 NULL NULL
NULL NULL 3 Казань

CROSS JOIN

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

SELECT *

FROM Person

CROSS JOIN City

или

SELECT *

FROM Person, City

Набор очевиден и содержит для данного случая 12 записей.

42) SQL. Понятие курсора.

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

Курсор в SQL – это область в памяти базы данных, которая предназначена для хранения последнего оператора SQL. Если текущий оператор – запрос к базе данных, в памяти сохраняется и строка данных запроса, называемая текущим значением, или текущей строкой курсора. Указанная область в памяти поименована и доступна для прикладных программ.

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

В соответствии со стандартом SQL при работе с курсорами можно выделить следующие основные действия:

* создание или объявление курсора;

* открытие курсора , т.е. наполнение его данными, которые сохраняются в многоуровневой памяти;

* выборка из курсора и изменение с его помощью строк данных;

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

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

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

В некоторых случаях применение курсора неизбежно. Однако по возможности этого следует избегать и работать со стандартными командами обработки данных: SELECT, UPDATE, INSERT, DELETE. Помимо того, что курсоры не позволяют проводить операции изменения над всем объемом данных, скорость выполнения операций обработки данных посредством курсора заметно ниже, чем у стандартных средств SQL.

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

Объявление курсора:

 

DECLARE имя_курсора CURSOR FOR SELECT текст_запроса

 

Таким образом, любой курсор создается на основе некоторого оператора SELECT.

Открытие курсора:

 

OPEN имя_курсора

 

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

Чтение следующей строки из курсора:

FETCH имя_курсора INTO список_переменных

Переменные в списке должны иметь тот же количество и тип, что и столбцы курсора. Глобальная переменная @@FETCH_STATUS принимает ненулевое значение, если строк в курсоре больше нет. Если же набор строк еще не исчерпан, то @@FETCH_STATUS равна нулю, и оператор FETCH перепишет значения полей из текущей строки в переменные.

Закрытие курсора:

 

CLOSE имя_курсора

 

Для удаления курсора из памяти используется команда

 

DEALLOCATE имя_курсора

 

Для иллюстрации использования курсора создадим процедуру для начисления пени по тем счетам, по которым истек срок платежа.

 

CREATE PROCEDURE peni @percent NUMERIC(5,2)

AS

DECLARE                    @num INT,

@dat DATETIME,

@days INT,

@sum NUMERIC(6)

 

IF @percent > 0 AND @percent < 100

 

BEGIN

DECLARE cur1 CURSOR FOR

SELECT bill_num, bill_term FROM k_bill b

WHERE bill_term

(SELECT SUM(payment_sum) FROM k_payment p

WHERE b.bill_num=p.bill_num)

OR NOT EXISTS

(SELECT bill_num FROM k_payment p

WHERE b.bill_num=p.bill_num)

)

 

OPEN cur1

FETCH cur1 INTO @num, @dat

 

WHILE @@FETCH_STATUS=0

BEGIN

SELECT @days=DATEDIFF(day, @dat, GETDATE())

 

SELECT @sum=ISNULL(SUM(payment_sum),0) FROM k_payment

WHERE @num=bill_num

 

UPDATE k_bill

SET bill_peni=(bill_sum-@sum)*@percent/100*@days

WHERE @num=bill_num

 

FETCH cur1 INTO @num, @dat

 

END

DEALLOCATE cur1

 

END

GO

Рассмотрим эту процедуру более подробно.

Параметром этой процедуры является процент для вычисления пени.

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

 

bill_sum>

(SELECT SUM(payment_sum) FROM k_payment p

WHERE b.bill_num=p.bill_num)

 

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

 

NOT EXISTS

(SELECT bill_num FROM k_payment p

WHERE b.bill_num=p.bill_num)

 

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

 

DATEDIFF(day, @dat, GETDATE())

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

Для запуска этой процедуры на выполнение нужно выполнить, например, команду

EXEC peni 0.5

43) SQL. Группировка данных. Использование обобщающих функций.

Применение агрегатных функций и вложенных запросов в операторе выбора

Имхо, более по-русски говорить «функции агрегирования». По крайней мере, так думает Акопов. – прим.ред.

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

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

Таблица 5.7. Агрегатные функции
Функция Результат
COUNT Количество строк или непустых значений полей, которые выбрал запрос
SUM Сумма всех выбранных значений данного поля
AVG Среднеарифметическое значение всех выбранных значений данного поля
MIN Наименьшее из всех выбранных значений данного поля
MAX Наибольшее из всех выбранных значений данного поля

 

Агрегатные функции используются подобно именам полей в операторе SELECT, но с одним исключением: они берут имя поля как аргумент. С функциями SUM и AVG могут использоваться только числовые поля. С функциями COUNT, MAX и MIN могут использоваться как числовые, так и символьные поля. При использовании с символьными полями MAX и MIN будут транслировать их в эквивалент ASCII кода и обрабатывать в алфавитном порядке.

 

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

 

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

 

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

В арифметических выражениях предикатов, входящих в условие выборки раздела HAVING, прямо можно использовать только спецификации столбцов, указанных в качестве столбцов группирования в разделе GROUP BY. Остальные столбцы можно специфицировать только внутри спецификаций агрегатных функций COUNT, SUM, AVG, MIN и MAX, вычисляющих в данном случае некоторое агрегатное значение для всей группы строк. Аналогично обстоит дело с подзапросами, входящими в предикаты условия выборки раздела HAVING: если в подзапросе используется характеристика текущей группы, то она может задаваться только путем ссылки на столбцы группирования.

Результатом выполнения раздела HAVING является сгруппированная таблица, содержащая только те группы строк, для которых результат вычисления условия поиска есть TRUE. В частности, если раздел HAVING присутствует в табличном выражении, не содержащем GROUP BY, то результатом его выполнения будет либо пустая таблица, либо результат выполнения предыдущих разделов табличного выражения, рассматриваемый как одна группа без столбцов группирования.

44) SQL. Возможности совместной обработки таблиц.

 

В запросах SELECT, UPDATE – перечисление искомых полей нескольких таблиц через прямое указание вида название_таблицы.название_поля, либо через параметр FROM [].

 

SELECT [STRAIGHT_JOIN]
       [DISTINCT | DISTINCTROW | ALL]
    expression,...
    [INTO {OUTFILE | DUMPFILE} 'file_name' export_options]
    [FROM table_references
      [WHERE where_definition]
      [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [HAVING where_definition]
      [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [LIMIT [offset,] rows]
      [PROCEDURE procedure_name]
      [FOR UPDATE | LOCK IN SHARE MODE]]

 

SELECT column1, column2
                   FROM table1, table2
                   WHERE […]

 

Объединение таблиц в запросе SELECT – см. 45. Группировка данных в запросе – см. 43.

45) SQL. Упорядочение данных. Операция объединения.

 

  1. Объединение таблиц
(SELECT) FROM <список исходных таблиц>
<   выражение естественного объединения >
<   выражение объединения >
<   выражение перекрестного объединения >
<   выражение запроса на объединение >
<список исходных таблиц>::= <имя_таблицы_1> [ имя синонима таблицы_1] [ …] [,<имя_таблицы_n>[ <имя синонима таблицы_n> ] ]
<выражение естественного объединения>:: =
<имя_таблицы_1> NATURAL { INNER | FULL [OUTER] LEFT [OUTER] | RIGHT [OUTER]} JOIN <имя_таблицы_2>
<выражение перекрестного объединения>:: = <имя_таблицы_1> CROSS JOIN <имя_таблицы_2>
<выражение запроса на объединение>::=
<имя_таблицы_1> UNION JOIN <имя_таблицы_2>
<выражение объединения>::= <имя_таблицы_1> { INNER
FULL [OUTER] | LEFT [OUTER] | RIGHT [OUTER]}
JOIN {ON условие | [USING (список столбцов)]} <имя_таблицы_2>

В этих определениях INNER — означает внутреннее объединение, LEFT — левое объединение, то есть в результат входят все строки таблицы 1, а части результирующих кортежей, для которых не было соответствующих значений в таблице 2, дополняются значениями NULL (неопределено). Ключевое слово RIGHT означает правое внешнее объединение, и в отличие от левого объединения в этом случае в результирующее отношение включаются все строки таблицы 2, а недостающие части из таблицы 1 дополняются неопределенными значениями, Ключевое слово FULL определяет полное внешнее объединение: и левое и правое. При полном внешнем объединении выполняются и правое и левое внешние объединения и в результирующее отношение включаются все строки из таблицы 1, дополненные неопределенными значениями, и все строки из таблицы 2, также дополненные неопределенными значениями.

Ключевое слово OUTER означает внешнее, но если заданы ключевые слова FULL, LEFT, RIGHT, то объединение всегда считается внешним.

MySQL не поддерживает ключевое условие FULL JOIN.

INNER JOIN возвращает строки, в которых есть хотя бы одно совпадение в обеих таблицах.

SQL INNER JOIN

SELECT column_name(s)FROM table_name1

INNER JOIN table_name2

ON table_name1.column_name=table_name2.column_name

INNER JOIN делает то же самое, что и JOIN.

SQL LEFT JOIN

LEFT JOIN возвращает все строки из левой таблицы (table_name1), даже если в правой таблице (table_name2) к ним нет совпадений.

SQL LEFT JOIN

SELECT column_name(s)FROM table_name1

LEFT JOIN table_name2

ON table_name1.column_name=table_name2.column_name

SQL RIGHT JOIN

RIGHT JOIN возвращает все строки из правой таблицы (table_name2), даже если в левой таблице (table_name1) к ним нет совпадений.

SQL RIGHT JOIN

SELECT column_name(s)FROM table_name1

RIGHT JOIN table_name2

ON table_name1.column_name=table_name2.column_name

 

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

 

Объединение запросов

SQL UNION

Оператор UNION используется для объединения наборов результатов от двух или более запросов SELECT.

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

SQL UNION

SELECT column_name(s) FROM table_name1UNION

SELECT column_name(s) FROM table_name2

Оператор UNION выбирает только различные значения. Для выбора с учетом повторов, используйте UNION ALL.

SQL UNION ALL

SELECT column_name(s) FROM table_name1UNION ALL

SELECT column_name(s) FROM table_name2

Названия столбцов в итоговом результате оператора UNION всегда совпадают с названиями в первом запросе  SELECT этого оператора.

46) SQL. Возможности задания состава колонок, выводимых в ответ.

Запрос SELECT способен извлечь  информацию из строго определенных столбцов таблицы. Для этого искомые столбцы перечисляются в запросе.

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

DISTINCT  – аргумент, устраняющий повторные значения из выборки запроса SELECT

 

Задание состава колонок при объединении таблиц:

  • JOIN <…> USING (column_list) служит для указания списка столбцов, которые должны существовать в обеих таблицах. Такое выражение USING, как:
  • семантически идентично выражению ON, например:
   A LEFT JOIN B USING (C1,C2,C3,...)

C1=B.C1 AND A.C2=B.C2 AND A.C3=B.C3,…

  • Выражение NATURAL [LEFT] JOIN для двух таблиц определяется так, чтобы оно являлось семантическим эквивалентом INNER JOIN или LEFT JOIN с выражением USING, в котором указаны все столбцы, имеющиеся в обеих таблицах.

При использовании представления (view),  набор колонок определяется запросом, создающим представление. Пример синтаксиса:

 

CREATE VIEW view1
          AS SELECT column1, column2, column(n)
          FROM table1, table2, table(n)
          WHERE [condition];

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

47) SQL. Возможности задания условий отбора.

SELECT — оператор DML языка SQL, возвращающий набор данных (выборку) из базы данных, удовлетворяющих заданному условию. В большинстве случаев, выборка осуществляется из одной или нескольких таблиц. В последнем случае говорят об операции слияния (англ. join). В тех СУБД, где реализованы представления и хранимые процедуры, также возможно получение соответствующих наборов данных.   SELECT [DISTINCT | DISTINCTROW | ALL] select_expression,… [FROM table_references [WHERE where_definition] [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], …] [HAVING where_definition] [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC], …]

    • WHERE — используется для определения, какие строки должны быть выбраны или включены в GROUP BY.

 

    • GROUP BY — используется для объединения строк с общими значениями в элементы меньшего набора строк.

 

    • HAVING — используется для определения, какие строки после GROUP BY должны быть выбраны.

 

  • ORDER BY — используется для определения, какие столбцы используются для сортировки результирующего набора данных.

Пример: SELECT f_name, l_name from employee_data where f_name = ‘Иван’;   Этот оператор выводит имена и фамилии всех сотрудников, которые имеют имя Иван. Отметим, что слово Иван в условии заключено в одиночные кавычки. Можно использовать также двойные кавычки. Кавычки являются обязательными, так как MySQL будет порождать ошибку при их отсутствии. Кроме того сравнения MySQL не различают регистр символов, что означает, что с равным успехом можно использовать “Иван”, “иван” и даже “ИвАн”.   Существуют различные оконные функции. ROW_NUMBER() OVER может быть использована для простого ограничения числа возвращаемых строк. Например, для возврата не более десяти строк:   SELECT * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY KEY ASC) AS rownumber, COLUMNS FROM tablename ) AS foo WHERE rownumber <= 10   оконная функция RANK()   Функция RANK() OVER работает почти так же, как ROW_NUMBER, но может вернуть более чем n строк при определённых условиях. Например, для получения top-10 самых молодых людей: SELECT * FROM ( SELECT RANK() OVER (ORDER BY age ASC) AS ranking, person_id, person_name, age FROM person ) AS foo WHERE ranking <= 10

В MySQL можно к запросу дописать LIMIT (0,30) – Это выведет первые 30 записей (или меньше, если в таблице меньше 30). Так делает phpMyAdmin – прим.ред.

48) SQL. Создание и использование представлений.

Представление – это виртуальная таблица, определяемая запросом, содержащим оператор SELECT. Эта виртуальная таблица состоит из данных одной или нескольких реальных таблиц, а для пользователей представление выглядит, как реальная таблица. И действительно, с представлением можно работать, как с обычной таблицей. Пользователи могут обращаться к этим виртуальным таблицам в операторах TrАnsАсt-SQL (T-SQL) таким же образом, как и к таблицам. К представлению можно применять операции SELECT, INSERT, UPDATE и DELETE. Синтаксис SQL CREATE VIEW:   CREATE VIEW view_name AS SELECT column_name(s) FROM table_name WHERE condition   На самом деле представление хранится просто как заранее определенный оператор SQL. При доступе к представлению оптимизатор запросов SQL Server объединяет текущий выполняемый оператор SQL с запросом, который был использован для определения данного представления.   Представление удаляется с помощью запроса: DROP VIEW view_name Представление обновляется при помощи: CREATE OR REPLACE VIEW view_name AS SELECT column_name(s) FROM table_name WHERE condition   Преимущество использования представлений заключается в том, что можно создавать представления с различными атрибутами без необходимости дублирования данных. Представления полезны в целом ряде ситуаций: –                 С помощью представлений обеспечивается ещё один уровень защиты данных –                 Использование представлений позволяет отделить прикладную схему представления данных от схемы хранения –                 Для слияния секционированных данных.

В Аксессе представления создаются с помощью мастеров, конструкторов, etc – прим. ред.

49) Возможности организации ввода информации в реляционных СУБД. Оператор INSERT заполняет таблицу данными. Вот общая форма INSERT. INSERT into table_name (column1, column2, …) values (value1, value2…);

    • Значениями для одних столбцов являются текстовые строки, и они записываются в кавычках.

 

    • Значениями для других являются числа (целые), и они не имеют кавычек.

 

  • Значение для ключевого столбца задает система MySQL, которая находит в столбце наибольшее значение, увеличивает его на единицу, и вставляет новое значение.

inc -это ключевое поле naim – в этом столбце мы указываем название товара. cena -в этом столбце мы указываем цену товара. kol -это количество товара. srok – это срок годности продукта.   Также в Access можно войти в режим Таблица и непосредственно забить данные с клавиатуры(Новая запись, Вставкаà новая запись, щёлкнуть мышью). Могут использоваться значения по умолчанию, формат поля и маска ввода. 1)             По умолчанию – постоянное значение, которое затем может быть изменено. 2)             Маска ввода – позволяет определить значения, которые можно ввести. Облегчает ввод и отслеживает правильность. 3)             Формат поля – влияет на отображение, но не на значение поля. Здесь полезно сказать о всех видах интерфейсов, которые можно разработать и которые можно поиметь готовыми. Это и оболочки типа MyManager, и скрипты в экселе на бейсике, и подключение к студии через ADO.NET, и PHP – прим.ред.

50) Генераторы экранных форм. Назначение экранных форм. Классификация. База данных, в которой отображается текущая деятельность компании, полезна только в том случае, если информация в ней постоянно обновляется, а поиск нужных сведений осуществляется быстро. Хотя ввод, корректировка и извлечение табличных данных не представляют особого труда, едва ли можно поручить эти функции пользователям, не имеющим представления о СУБД. Дело не только в неэффективности подобного подхода, но и в количестве ошибок, возникающих при работе в непосредственно в таблице, особенно при вводе информации в связанные таблицы. Решением этой проблемы – и первым шагом на пути превращения базы данных в приложение – являются формы. Форма представляет собой объект базы данных, содержащий упорядоченный набор элементов управления, которые обеспечивают интерактивное взаимодействие с полями одной или нескольких таблиц. С помощью элементов управления можно вводить новые данные, редактировать и удалять существующие и осуществлять поиск информации. Подобно печатным формам, формы, включают поля, предназначенные для ввода данных, и надписи к ним. Но в отличие от печатных форм, они могут включать такие элементы, как кнопки выбора или командные кнопки. На экранных формах можно организовать выбор информации из таблиц-справочников с использованием раскрывающихся списков или отдельных окон, использовать специальные режимы редактирования данных с сохранением или отменой изменений, режимы поиска и отбора информации, печати необходимых отчетов на принтере и пр.

Экранные формы можно классифицировать (рис. 8.1) по ряду признаков.

1.    По характеру связи с таблицами различают связанные и не связанные экранные формы. Если форма отражает какие-либо данные из таблиц баз данных, она называется связанной (или присоединенной), в противном случае – несвязанной. По числу используемых таблиц выделяют однотабличные и многотабличные формы. По характеру соподчинения отдельных частей многотабличные формы классифицируются как простые, иерархические и синхронизированные. Простые многотабличные формы хотя и содержат данные из разных таблиц, но не имеют в своем составе соподчиненных частей. Такие формы могут возникнуть, например, когда они базируются на таблицах, связанных друг с другом отношением 1:1, или когда в форму выводятся данные из таблиц, связанных друг с другом отношением 1 :М, но в форму в основном выводятся данные, находящиеся со стороны «М», а из таблицы, находящейся со стороны «1», берутся какие-то, обычно справочные, данные, т.е. ведущим здесь как бы является таблица, находящаяся со стороны «М». Но наиболее естественной для многотабличных форм все-таки является ситуация, когда ведущая таблица находится на стороне «1». В этом случае создаются иерархические формы, когда в форму в ее общей части выводятся данные из одной записи ведущей таблицы, а в табличной части – множество связанных с ней записей ведомого (зависимого) файла. Иногда (по разным причинам) бывает нецелесообразно выводить в одну иерархическую форму данные и из основного, и из зависимого файла, и данные из зависимого файла выводятся в отдельной «зоне», которая открывается «при нажатии» соответствующей управляющей кнопки. Такие формы называются синхронизированными.

2.   По выполняемым функциям различают формы ввода, вывода, управляющие, смешанные. Назначение каждого вида этих форм ясно из их названия. Следует обратить внимание на то, что даже в случае, если формы для ввода и вывода полностью совпадают по своему внешнему виду, иногда целесообразно их выполнить как самостоятельные формы в целях обеспечения безопасности данных. 3.    По распределению данных по экранам (страницам) формы делятся на одностраничные и многостраничные; одной из разновидностей многостраничных форм можно считать формы с вкладками. 4.    По способу реализации экранные формы могут быть всплывающими и невсплывающими. Всплывающая форма располагается поверх других открытых форм, даже если активной является другая форма. Всплывающая форма может быть немодальной или модальной. Если всплывающая форма – модальная, пользователь имеет возможность получить доступ к другим объектам и командам меню, пока форма открыта. Если всплывающая форма является немодальной, нельзя получить доступ к любым другим объектам или командам меню, пока форма открыта. Пользователь должен выполнить какое-либо действие, чтобы фокус был переключен на другую форму (или окно). 5.    По форме представления информации экранные формы могут содержать символьную информацию, деловую графику, информацию, представленную в мультимедийной форме. Например, в БД, хранящей информацию о животных, наряду с описанием каждого вида может выводиться изображение животного и воспроизводиться издаваемый им звук. Несмотря на такое широкое применение экранных форм для реализации разных целей, основное внимание далее уделим их использованию для организации ввода данных в БД, потому что, во-первых, это является одним из основных назначений экранных форм; во-вторых, именно этот аспект наиболее значим для процессов создания и ведения БД; в-третьих, такие функции, как создание меню, вывод информации из БД и т.п., могут выполняться с использованием и других средств СУБД.

51)    Характеристика генератора экранных форм конкретной СУБД. Форму можно создать тремя различными способами. При помощи автоформы на основе таблицы или запроса. С помощью автоформ можно создавать формы, в которых выводятся все поля и записи базовой таблицы или запроса. Если выбранный источник записей  имеет связанные таблицы или запросы, то в форме также будут присутствовать все поля и записи этих источников записей. Инструкции

    1. В окне базы данных нажмите кнопку Формы на панели Объекты.

 

    1. На панели инструментов окна базы данных нажмите кнопку Создать.

 

  1. В диалоговом окне Новая форма выберите мастера.
    • Автоформа: в столбец .   Каждое поле располагается на отдельной строке; подпись находится слева от поля.

 

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

 

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

 

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

 

  • Автоформа: сводная диаграмма .   Форма открывается в режиме сводной диаграммы. Имеется возможность добавлять поля путем их перетаскивания из списка полей в различные области макета.
    1. Выберите таблицу или запрос, содержащие данные, на основе которых создается форма.

 

  1. Нажмите кнопку OK.

Microsoft Access применяет к форме автоформат, который использовался последним. Если до этого формы с помощью мастера не создавались и не использовалась команда Автоформат в меню Формат, будет применяться стандартный автоформат. Можно также создать автоформу в столбец на основе открытого источника записей или на основе источника записей, выделенного в окне базы данных. Выберите команду Автоформа в меню Вставка или щелкните стрелку рядом с кнопкой Новый объект на панели инструментов и выберите команду Автоформа. Если выбранный источник записей имеет связанные таблицы, автоформа добавляет подчиненную форму, которая содержит связанные таблицы, отображаемые как таблицы  и подтаблицы. При помощи мастера на основе одной или нескольких таблиц или запросов. Мастер задает подробные вопросы об источниках записей, полях, макете, требуемых форматах и создает форму на основании полученных ответов.

    1. В окне базы данных (Окно базы данных. В Microsoft Access 2003 и предыдущих версий — окно, которое открывается при открытии базы данных или проекта. В окне базы данных отображаются ярлыки для создания новых объектов базы данных и открытия существующих объектов. В более поздних версиях этот элемент заменен областью навигации.) нажмите кнопку Формы на панели Объекты.

 

    1. На панели инструментов окна базы данных нажмите кнопку Создать.

 

    1. В диалоговом окне Новая форма выберите нужного мастера. Описание мастера появляется в левой части диалогового окна.

 

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

 

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

    1. Нажмите кнопку OK.

 

    1. Следуйте инструкциям мастера.

 

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

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

 

    • Если была выбрана одна из автоформ, то к новой форме будет применен автоформат , который использовался последним (либо в мастере форм, либо с помощью команды Автоформат меню Формат в режиме конструктора).

 

Вручную в режиме конструктора. Сначала создается базовая форма, которая затем изменяется в соответствии с требованиями в режиме конструктора .

    1. В окне базы данных  нажмите кнопку Формы на панели Объекты.

 

    1. На панели инструментов окна базы данных нажмите кнопку Создать.

 

    1. В диалоговом окне Новая форма выберите строку Конструктор.

 

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

 

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

    1. Нажмите кнопку OK.

 

Форма будет открыта в режиме конструктора.

52) Генераторы отчетов. Классификация отчетов.

Термин «отчет» понимается в ИС шире, чем это традиционно принято. Под отчетом здесь понимается любой выходной документ: список (например, сотрудников), письмо, адрес, печатающийся на конверте (почтовая этикетка), отчет в традиционном понимании этого слова. Создание отчетов (выходных документов) является одной из наиболее важных функций информационных систем. Для создания отчетов используются высокоуровневые средства автоматизации – генераторы отчетов. Генераторы отчетов, так же как и генераторы форм ввода-вывода, являются компонентами языков 4-го поколения. Они включены в состав большинства СУБД. Кроме того, генераторы отчетов представлены и как самостоятельный класс программного обеспечения. Существует даже англоязычный термин «reporting», объединяющий все вопросы, относящиеся к процессу получения отчетов. Чаще всего, когда отчеты обсуждаются в контексте БД, речь идет об извлечении информации из каких-либо источников (однотипных или разнотипных) и представлении их в виде, удобном для дальнейшего восприятия и анализа. Это делает рассматриваемые вопросы близкими к проблематике OLAP-систем. Источниками для получения отчетов могут быть не только таблицы баз данных, но и запросы, а также записи, отобранные с помощью фильтров. Некоторые генераторы отчетов позволяют проводить отбор данных, включаемых в отчет, непосредственно пользуясь средствами самого генератора отчетов.   Отчеты позволяют выполнять следующие действия:

·   проводить группировку данных;

·   вычислять многоуровневые промежуточные и общие итоги по отдельным полям; ·        вводить в отчеты вычисляемые поля;

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

·  включать в отчеты данные, отобранные по заданным критериям;

·  использовать различные формы представления информации;

·  качественно оформлять выводимые данные.

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

Различают отчеты анкетной и табличной формы. При анкетной форме данные об одном объекте (сотруднике, товаре и т.п.) обычно размещаются один под другим, причем слева указывается название атрибута (поля), а справа – его значение. После вывода информации об одном объекте выводится информация о следующем объекте (рис. 9.2). Иногда такой тип документа называют документом в виде формы (действительно, это очень напоминает позаписный вывод информации на экран при использовании экранных форм). Документы табличной формы включают в себя привычные таблицы с названиями атрибутов в заголовках столбцов; данные о каждом объекте представляются в одной строке (рис. 9.3). Табличные документы могут включать либо одну таблицу – однотабличные документы, либо несколько таблиц (обычно разной структуры) – многотабличные документы. В зависимости от объема и выбранного способа оформления документы могут занимать одну страницу (одностраничные) или несколько страниц (многостраничные). В любом документе могут быть выделены самостоятельные разделы (зоны, «полосы», области), выполняющие разную смысловую нагрузку. В реальном документе те или иные из перечисленных ниже зон могут отсутствовать. Различают зоны, относящиеся целиком к документу; это заголовок отчета и примечание документа («итоговая» зона, оформительская часть). Заголовок отчета и примечание отчета могут размещаться на первой и последней страницах отчета соответственно либо выноситься на отдельные листы.

Для каждой страницы выделяют верхний и нижний колонтитулы (заголовок и «подножие» страницы). Ну и, естественно, главное место принадлежит области данных. В этой области размещаются данные из БД. Источниками информации для отчетов могут быть либо реальные таблицы базы данных, либо предварительно созданные запросы, отбирающие информацию, выводимую в отчет. Кроме того, в отчет могут включаться вычисляемые поля. Вычисляемые поля, как, впрочем, и реальные поля БД, могут входить в любую зону документа. В последнее время в отчеты, наряду с символьной информацией, часто включается деловая графика. Кроме документов, содержащих главным образом фактографическую информацию из баз данных, можно создавать и документы, которые в основном, напротив, включают какой-то текст (документографические), в который вкраплены данные из БД (документы типа письма). В документах фактографического типа можно различать просто какой-то текст, не имеющий жесткой связи с элементами БД (например, название документа, поясняющий текст), названия элементов из БД (например, «Фамилия») и значения этих элементов (например, Иванов, Петров), элементы оформления (линия, рисунки). Генераторы отчетов разных СУБД различаются по своим возможностям и особенностям выполнения идентичных функций. Так, например, в некоторых системах в итоговую зону документа по умолчанию включаются суммарные величины всех числовых полей, включенных в отчет. Необходимо внимательно проанализировать отчет, полученный в результате применения Мастера, и внести необходимые изменения в форму отчета. Перечни типов отчетов, которые предлагает та или иная СУБД, могут различаться. В Access такой тип отчетов отсутствует, но это не означает, что нельзя получить документ такого типа. Просто нужно воспользоваться другими возможностями, в частности возможностью создания составного документа путем слияния.

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

Выбор источника записей

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

Создание простого отчета с помощью мастера отчетов

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

Чтобы создать отчет с помощью мастера отчетов, выполните следующие действия:

 

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

 

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

 

    1. Щелкните список Создать объект на панели инструментов.

 

    1. Выберите Автоотчет.

 

Access выведет на экран отчет. – ИЛИ –

    1. В окне базы данных выберите Отчеты.

 

    1. На панели инструментов в окне базы данных выберите Создать.

 

    1. В диалоговом окне Создание отчета выберите один из следующих вариантов:

 

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

    1. Выберите таблицу или запрос для отчета.

 

    1. Нажмите кнопку ОК.

 

Access применяет автоформатирование, которое использовалось для форматирования отчета в прошлый раз. Если раньше отчеты в мастере не создавались или не использовалась команда Автоформат в меню Формат, Access использует стандартное автоформатирование.

Чтобы создать отчет в другом мастере отчетов, выполните следующие действия:

 

    1. В окне базы данных выберите Отчеты.

 

    1. В окне базы данных выберите Создать.

 

    1. Откроется диалоговое окно Создание отчета.

 

    1. Выберите один из вариантов из списка.

 

    1. Выберите таблицу или запрос для отчета и нажмите кнопку ОК.

 

    1. Следуйте указаниям мастера отчетов. На последней странице нажмите кнопку Готово.

 

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

 

Разделы отчета

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

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

 

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

 

    • Заголовок группы. Печатается в начале каждой новой группы записей. В заголовке группы печатается имя группы. Например, в отчете с группировкой по продукту в качестве заголовка группы можно указать наименование продукта. Если в заголовке группы размещается вычисляемый элемент управления с функцией суммирования Sum, рассчитанная сумма отражает итог по всей группе.

 

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

 

    • Примечание группы. Печатается в конце каждой группы записей. Здесь размещаются итоги по группе.

 

    • Примечание страницы. Печатается в конце каждой страницы. Здесь размещаются номера страницы или иные сведения о странице.

 

    • Примечание отчета. Печатается один раз в конце отчета. В примечании отчета печатаются итоговые сведения и иная статистика по всему отчету. Обратите внимание на то, что примечание отчета в представлении «Конструктор» идет последним, но печатается до примечания последней страницы.

 

 

Последние штрихи к отчету в представлении «Конструктор»

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

    • В меню Вид выберите Режим конструктора (или нажмите стрелку рядом с кнопкой Вид на панели инструментов и выберите Режим конструктора).

 

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

    • Присоединенные элементы управления. Элемент управления, источником данных которого является поле таблицы или запроса, называется присоединенным . В присоединенных элементах управления отображаются значения полей базы данных. Это могут быть текстовые значения, даты, числа, значения да/нет, рисунки и графики. Самым распространенным типом присоединенного элемента управления является текстовое поле. Например, в текстовое поле в форме, содержащей фамилию сотрудника, эти данные могут быть добавлены из поля «Фамилия» таблицы «Сотрудники».

 

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

 

    • Вычисляемые элементы управления. Элемент управления, источником данных которого является выражение, а не поле, называется вычисляемым . Значение такого элемента управления определяется выражением, которое является его источником данных. Выражение представляет собой сочетание операторов (таких как = и +), имен элементов управления, имен полей, функций, возвращающих одно значение, и постоянных величин. Например, следующим выражением рассчитывается цена товара со скидкой 25% путем умножения значения поля «Цена за единицу» на постоянную величину (0,75).

 

 

= [Цена за единицу] * 0.75

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

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

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

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

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

  • К присоединенному текстовому полю присоединена надпись, которая по умолчанию воспринимает имя поля (или заголовок, определенный для этого поля в исходной таблице или запросе) в качестве его заголовка, поэтому вводить заголовок отдельно не придется.
  • Присоединенное текстовое поле наследует многие параметры поля исходной таблицы или запроса (например, свойства Формат, Число десятичных знаков и Маска ввода). Поэтому можно быть уверенным, что эти свойства поля останутся такими же при создании текстового поля, присоединенного к этому полю.

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

Добавление полей в отчет

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

Чтобы вывести на экран список полей, выполните следующие действия:

  • В меню Вид выберите Список полей (или нажмите кнопку Список полей на панели инструментов).
  • Чтобы добавить одно поле, перетащите его из списка полей в тот раздел отчета, где оно будет находиться.
  • Чтобы добавить несколько соседних полей одновременно, щелкните первое поле и, удерживая нажатой клавишу SHIFT, щелкните последнее поле. Перетащите выделенные поля в отчет.
  • Чтобы добавить одновременно несколько полей из разных частей списка, щелкните первое поле, а затем, удерживая нажатой клавишу CTRL, щелкните остальные поля. Перетащите выделенные поля в отчет.

Чтобы добавить поля из списка полей, выполните следующие действия:

При перетаскивании полей в отчет Access создает для каждого из них присоединенное текстовое поле и автоматически размещает около каждого текстового поля элемент управления «надпись».

Добавление элементов управления в отчет

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

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

Чтобы открыть или закрыть панель элементов, выполните следующие действия:

  • В меню Вид выберите Панель элементов (или нажмите кнопку Панель элементов на панели инструментов).

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

  • Поместите указатель мыши на элементе.

На экране появится имя инструмента.

Чтобы создать элемент управления с помощью панели элементов, выполните следующие действия:

  • Щелкните инструмент того типа элемента управления, который нужно добавить. Например, чтобы создать флажок, выберите Флажок.
  • Чтобы создать присоединенный элемент управления, выделите поле в списке полей и перетащите его в отчет.

—или—

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

 

54) Классификация распределенных банков данных.

 

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

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

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

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

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

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

При сравнении децентрализованных и распределенных систем (табл. 10.2) знаком «+» отмечены лучшие значения характеристики.

Таблица 10.2

Характеристика Система
децентрализованная распределенная
Возможность совместного использования данных +
Сложность используемыхпрограммных средств +
Возможность централизованногообеспечения целостности данных +
Сложность проектирования +
Сложность поддержаниябезопасности +
Гибкость и эффективностьиспользования вычислительных ресурсов +

В РБнД с централизованной БД (много клиентов/один сервер) проблемы управления базой данных решаются относительно просто, поскольку вся она хранится на одном сервере. Задачи, с которыми приходится здесь сталкиваться, – это блокировки при одновременном обращении к данным, управление буферами клиентов и кэширование данных. Управление данными реализуется централизованно на одном сервере.

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

Таблица 10.3

Характеристика Система
централизованная распределенная
Сложность используемых программных средств +
Уязвимость БД +
Потери на непроизводительные (накладные) расходы +
Ограничение пропускной способности +
Модульность, возможность расширения системы +
Сложность проектирования +
Сложность поддержания актуальности БД +
Сложность поддержания целостности БД +
Сложность поддержания безопасности +
Возможность уменьшения сетевого трафика +
Распределение рабочей нагрузки естественным образом на несколько компьютеров +
Соотношение показателя «стоимость/ эффективность» +
Требования к аппаратной платформе +
Сложность администрирования +

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

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

На выбор способа организации БД оказывают влияние следующие факторы:

·        число пользователей;

·        степень пересечения информационных потребностей пользователей;

·        объем данных;

·        квалификация персонала;

·        ограничения (стоимость, время отклика, актуальность информации);

·        наличие существующей системы обработки информации и ее характеристика.

Несмотря на то что при использовании распределенных систем используется более сложное и дорогое программное обеспечение, более совершенные технические средства, наибольшие затраты здесь приходятся на эксплуатационные расходы. По данным фирмы Microsoft[††††], структура затрат в централизованных и распределенных системах выглядит следующим образом:

·        в централизованных системах около половины (48%) средств расходуется на аппаратное обеспечение, 14% составляют затраты на программное обеспечение и 28% – на поддержку системы;

·        в распределенных системах основные затраты (77%) связаны с поддержкой системы, расходы на аппаратное обеспечение составляют 15%, а на программное обеспечение – только 6% общей стоимости системы.

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

1.     централизованный каталог;

2.     полностью реплицированный каталог;

3.     секционированный каталог;

4.     комбинированный (1 и 3).

По способу взаимодействия функциональных компонентов различают файл-серверную и клиент-серверную архитектуру РБнД. На рис. 10.2 представлена принципиальная схема обработки данных в архитектуре «файл-сервер». При использовании такой архитектурной модели основная обработка данных проводится на рабочей станции. Такая модель приводит к необходимости передачи больших объемов данных по сети, что увеличивает трафик, а это, в свою очередь, может привести к замедлению обработки данных, увеличению стоимости, снижению надежности и другим недостаткам.

 

В системах с «клиент-серверной» архитектурой (рис. 10.3) основная обработка данных проводится на сервере.

«Клиент-серверные» системы имеют следующие преимущества:

·        снижение сетевого трафика за счет выполнения запросов на сервере;

·        оптимизация выполнения запросов;

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

·        возможность использования CASE-средств для генерации кодов серверных объектов (триггеров, хранимых процедур, текстов SQL-запросов);

·        управление пользовательскими привилегиями и правами доступа;

·        широкие возможности резервного копирования и архивации данных.

Сравнительные характеристики технологий «файл-сервер» и «клиент-сервер» приведены в табл. 10.4.

Таблица 10.4

Характеристика «Файл-сервер» «Клиент-сервер»
Интенсивность сетевого трафика +
Обеспечение целостности данных +
Обеспечение безопасности данных +
Устойчивость к сбоям +
Сложность проектирования +
Сложность эксплуатации системы +
Ограничения на число пользователей +

При обработке данных в сетевой среде выделяют следующие основные группы выполняемых функций:

·        презентационная логика (Presentation Layer – PL);

·        бизнес-логика (Business Layer – BL);

·        логика доступа к ресурсам (Access Layer – AL).

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

Модель с тонким клиентом стала активно использоваться в корпоративной среде в связи с распространением интернет-технологий, и в первую очередь Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.

Модель с толстым клиентом наиболее часто встречается в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL. Серверная часть при описанном подходе представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA – Remote Data Access.

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

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

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

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

55) Особенности проектирования распределенных БД.

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

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

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

Решение о распределенной базе данных оправданно и для систем, где есть четко выраженные группа меняющихся данных и группа устойчивых данных, по которым выполняются отчеты. Тогда в самом простом варианте работают два сервера: один обслуживает часто меняющиеся данные – это, как правило, OLTP (On-Line Transaction Processing. – Прим. ред.), второй – отчеты, то есть DSS (Decision Support System. – Прим. ред.). Ряд СУБД не очень хорошо совмещает обработку OLTP- и DSS-потоков запросов, поскольку для этих двух типов потоков запросов оптимальные параметры конфигурации серверов будут различаться. Решение такой базы данных как распределенной может оказаться более выгодным.

Преимущества распределенной базы данных имеют свою цену – должны быть обеспечены:

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

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

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

В распределенной базе данных могут быть использованы следующие типы вызовов:

  • Удаленные DDL- и DML- операции, а также выборка данных.
  • Синхронные удаленные вызовы процедур.
  • Асинхронные удаленные вызовы процедур.
  • Непротиворечивые снимки.
  • Асинхронная симметричная репликация.
  • Синхронная симметричная репликация.
  • Вызов распределенного запроса (запрашивает данные на чтение и модификацию с нескольких узлов).

Распределенная база данных может обеспечить горизонтальную фрагментацию; например, в филиале чаще всего используют данные о клиентах, находящихся в городе N (CLIENT_PLACE = ‘N’). В этом случае на узле распределенной базы данных этого филиала может быть расположен фрагмент таблицы данных, выделенный согласно условию CLIENT_PLACE = ‘N’.

Стратегия распределения данных для каждой СУБД определяется по-своему и достойна отдельной книги. Определение стратегии преследует две цели: сократить нагрузку на сеть и сервер и/или повысить уровень готовности данных.

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

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

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

Метод распределения данных по дискам для поддержки параллельных вычислений во многом зависит и от особенностей реализации СУБД. Администратор базы данных не может выбрать такой метод в отрыве от особенностей конкретной информационной системы. Еще одна возможность параллельной обработки данных, предоставляемая СУБД: обработка одного запроса несколькими менеджерами ресурсов. В реализациях также имеется возможность использования одного хранилища данных несколькими серверами баз данных (Parallel Server). Такая архитектура может быть эффективно использована на кластерах.

56) Проблемы обеспечения целостности в распределенных БД.

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

1.возможность одновременного доступа нескольких пользователей к одной и той же информации (особенно если эти обращения к БД – корректирующие);

2.физический разброс отдельных частей БД по разным компьютерам;

3.разнотипность источников информации.

Первая проблема имеет место в любых РБнД, вторая – если база данных является распределенной, третья – если система является гетерогенной.

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

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

·        запрещение корректировки информации, если ее корректирует другой пользователь (блокировка);

·        корректировка разных копий информационных единиц и последующее устранение возникающих коллизий.

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

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

·        ограничения на время реакции системы,

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

·        характеристика технических средств.

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

Как известно, существует два подхода к обеспечению целостности в распределенных информационных системах – строгая целостность (tight consistency) и нестрогая целостность (loose consistency). Первый вариант гарантирует целостность данных в любой момент времени, например, с помощью двухфазного протокола фиксаций (2РС). Обеспечение строгой целостности требует высокого качества коммуникаций, поскольку все узлы должны быть постоянно доступны. Второй подход допускает наличие временной задержки между внесением изменений в публикуемую базу и их отражением на узлах подписчиков.

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

Механизм двухфазной фиксации транзакции имеет ряд недостатков:

·        захват всех необходимых данных на всех серверах может надолго заблокировать доступ к данным;

велика вероятность отказа от обновления из-за какой-нибудь, пусть единичной, ошибки;

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

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

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

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

Разные СУБД поддерживают разные технологии обеспечения целостности.

57) Сравнение централизованных и распределенных систем.

По организации и технологии обработки данных базы данных подразделяются на централизованные и распределенные.

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

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

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

 

 

58) Распределенные БД. Технология клиент – сервер.

 

 

Распределенные БД (DDB) – совокупность множества взаимосвязанных БД, распределенных в компьютерной сети. Существует способ взаимодействия функциональных компонентов в сети, называемый  Клиент-сервер. При такой архитектуре построения БД:

– на выделенном сервере, работающем под управлением серверной ОС, устанавливается сервер БД;

– СУБД подразделяется на две части: клиентскую и серверную;

– осуществляется получение данных с сервера с помощью SQL-запросов и передача отобранных на рабочую станцию данных

Приемущества:

  • Снижение сетевого трафика (выполнение запросов на сервере)

Клиенту передается на весь файл БД, а только результат запроса – прим. ред.

  • Оптимизация выполнения запросов
  • Возможность хранения бизнес-правил на сервере (ограничение целостности и тд)
  • Возможность использования case средств для генерации кодов серверный объектов (триггеров и тд)
  • Управление пользовательскими привилегиями и правами доступа
  • Широкие возможности резервного копирования и архивации данных

Недостатки: ограниченное число пользователей

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

В классической архитектуре клиент-сервер приходится распределять три основные части приложения по двум физическим модулям. Обычно ПО хранения данных располагается на сервере, интерфейс с пользователем – на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями – либо на стороне клиента (“толстый” клиент), либо на сервере (“тонкий” клиент, или архитектура, называемая “2,5- уровневый клиент-сервер”).

Многоуровневые архитектуры клиент-сервер более разумно распределяют модули обработки данных, которые в этом случае выполняются на одном или нескольких отдельных серверах, называемых серверами приложений. Эти программные модули выполняют функции сервера для интерфейсов с пользователями и клиента – для серверов баз данных.  Например, трехуровневая архитектура функционирует в Интранет- и Интернет-сетях. Клиентская часть, взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных.

 

59) Распределенные базы данных. Технология тиражирования.

Распределенные БД (DDB)совокупность множества взаимосвязанных БД, распределенных в компьютерной сети. Используются разные технологии распределения данных по узлам сети, в частности – технология тиражирования. Distributed Database – прим. ред.

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

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

Преимущества технологии:

1) данные всегда расположены там, где они обрабатываются — следовательно, скорость доступа к ним существенно увеличивается.

2) передача только операций, изменяющих данные => уменьшение трафика.

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

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

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

60) Сетевые возможности современных СУБД.

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

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

 

61) Распределенные гетерогенные банки данных.

 

В зависимости от однородности компонентов  РБнД могут быть разделены на однородные или на разнородные (гетерогенные системы). В связи с тем, что процесс создания ИС практически непрерывен, то обычно эти системы являются разнородными. Чаще всего эта классификация производится относительно  используемых ЭВМ и СУБД. Гетерогенные системы более сложные и гибкие, они облегчают интеграцию разнородных информационных источников, структурированных, слабоструктурированных и иногда даже неструктурированных.

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

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

Примеры гетерогенных систем: EDA/SQL from Information Builders Corp., , IBM DataJoiner, User Data Management System (UDMS) from Unidata, Inc., ODBC Development Toolkit 1.2 from Automation Technology Inc.

Недостатки

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

 

 

62) Проблемы, возникающие при параллельном доступе, и пути их решения.

1) проблема утраченных обновлений

Суть – пользователи параллельно обрабатывают одни и те же данные, поэтому запоминается только то обновление, которое было проведено последним.

2) проблема незафиксированности обновлений (преждевременного чтения)

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

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

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

Пути решения

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

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

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

Обеспечивает

– согласованное и синхронное изменение распределенной БД параллельными транзакциями

– поддержку целостности и непротиворечивости данных

– предотвращение тупиковых ситуаций

– блокировку или возврат к исходной точке модификации во всех узлах.

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

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

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

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

 

63) Напишите код PHP, обеспечивающий подключение к условной базе данных MySQL с выполнением запроса типа “select  *  from  table” (без последующей обработки запроса).

<?PHP

$hostname = “localhost”;

$username = “myusername”;

$password = “mypassword”;

$dbName = “products”;

$link = MYSQL_CONNECT($hostname,$username,$password) OR DIE(“Не могу создать соединение “);

mysql_select_db(“$dbName”); mysql_select_db(“$dbName”);

$strSQL1 =  “select * from scenar “;

$zapr1=mssql_query($strSQL1);

/* обработка запроса*/

MYSQL_CLOSE();

?>

63

<?php

//подключаемся к бд на сервере localhost

$db = mysql_connect(“localhost”,”user”,”pass”);

mysql_select_db(“tables”,$db);

//даем команду на выполнение запроса

$result = mysql_query (“SELECT * FROM table”, $db);

?>

64-65

Надо написать html-форму.

<form action=myphpfile.php method=GET> ИЛИ POST.

<input type=text name=mytext id=mytext>

<input type =submit value=Отправить>  – это кнопка «Отправить, которая методом Пост или Гет передает массив пар ключ-значение, где ключи – это имена элементов input, скрипту, который прописан в action»

</form>

При нажатии на кнопку данные передаются в myphpfile.php, и он открывается. Из этого файла можно обращаться к элментам массива POST (или GET) не по индексам, а по ключам, например $_POST[‘mytext’]

 

//открываем php код

<?php

//проверяем, передана ли переменная value через глобальный массив POST. Можно еще передавать через массив GET, тогда нужно везде POST заменить на GET

If (IsSet($_POST[‘action’])&&$_POST[‘action’]!=‘’)

{

//присваиваем переданное значение некоторой переменной

$value = $_POST[‘value’];

//можно здесь какой-нибудь обработчик, но мы просто выведем переданное значение

echo $value;

}

?>

66

<?php

//подключаемся к бд на сервере localhost

$db = mysql_connect(“localhost”,”user”,”pass”);

mysql_select_db(“tables”,$db);

//даем команду на выполнение запроса

$result = mysql_query (“SELECT * FROM table”, $db);

//теперь забираем по одной все найденные записи

while ($myrow=mysql_fetch_array($result)){

//и из каждой записи выберем, например поле id

Echo $myrow[‘id’];

}

?>

67

EMS SQL Manager for MySQL – это высокопроизводительная программа для разработки и администрирования баз данных MySQL. SQL Manager for MySQL работает с любыми версиями MySQL, начиная с версии 3.23 поддерживает все самые новые функции MySQL, включая триггеры, представления, хранимые процедуры и функции, внешние ключи для таблиц InnoDB, UNICODE данные и другие. SQL Manager for MySQL позволяет быстро и просто создавать и редактировать все объекты баз данных MySQL, визуально проектировать базы данных MySQL, выполнять сценарии SQL, импортировать и экспортировать базы данных MySQL, управлять пользователями и их привилегиями, а также предоставляет множество полезных инструментов для эффективного администрирования MySQL. Современный графический интерфейс и грамотная система мастеров настроек предельно просты и будут понятны даже начинающему пользователю.

Ключевые особенности

  • Полная совместимость со всеми версиями MySQL, начиная с 3.23 по 6.0 включительно
  • Поддержка данных UTF8
  • Быстрая навигация и управление базами данных
  • Элементарное управление всеми объектами MySQL
  • Эффективные инструменты управления данными
  • Эффективное управление параметрами безопасности
  • Великолепные графические и текстовые инструменты для построения запросов
  • Впечатляющие возможности импорта и экспорта данных
  • Конструктор отчетов с понятным мастером создания отчетов
  • Мощный визуальный конструктор баз данных
  • Удобные мастера для выполнения сервисов MySQL
  • Доступ к серверу MySQL по HTTP протоколу HTTP туннелю
  • Доступ к серверу MySQL по HTTP протоколу SSH туннелю

68-69

ADO (от англ. ActiveX Data Objects — «объекты данных ActiveX») — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде.

Описание

Объектная модель ADO состоит из следующих объектов высокого уровня и семейств объектов:

  • Connection (представляет подключение к удалённому источнику данных)
  • Recordset (представляет набор строк, полученный от источника данных)
  • Command (используется для выполнения команд и SQL-запросов с параметрами)
  • Record (может представлять одну запись объекта Recordset или же иерархическую структуру, состоящую из текстовых данных)
  • Stream (используется для чтения и записи потоковых данных, например, документов XML или двоичных объектов)
  • Errors (представляет ошибки)
  • Fields (представляет столбцы таблицы базы данных)
  • Parameters (представляет набор параметров SQL-инструкции)
  • Properties (представляет набор свойств объекта)

Компоненты ADO используются в языках высокого уровня, таких как VBScript в ASP, Visual Basic и Delphi.

Set dbs = New Connection

Set rs = New Recordset

Set cnn1 = New ADODB.Connection

dbs.ConnectionString = “driver={SQL Server};” & _

“server=localhost; uid=sa;pwd=;database= SAMPLE”

dbs.ConnectionTimeout = 5

dbs.Open

sSQL = “select * from TEST”

rs.Open sSQL, dbs, adOpenDynamic, adLockOptimistic, -1

For j = 1 To rs.Fields.Count

i = 1

rs.MoveFirst

While Not rs.EOF

Cells(i, j) = rs.Fields(j – 1).Value

i = i + 1

rs.MoveNext

Wend

Next j

Set rs = Nothing

dbs.Close

 

Есть еще ADO.NET  – оно позволяет работать с БД из Visual Studio – прим. ред.

70

ODBC (Open DataBase Connectivity) — это программный интерфейс (API) доступа к СУБД, разработанный консорциумом X/Open. Позволяет единообразно оперировать с разными источниками данных, абстрагируясь от особенностей взаимодействия в каждом конкретном случае.

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

 

71) Как можно считать данные с ячейки рабочей книги MS Excel и сохранить их в СУБД с использованием ADO и VBA?

1) Подключаемся к СУБД с помощью ADO, в данном случае СУБД MySQL.

Set dbs = New Connection

Set rs = New Recordset

Set cnn1 = New ADODB.Connection

dbs.ConnectionString = “MySQL”

dbs.Open

2) Выбираем таблицу из БД, в которую будем сохранять данные (models).

sSQL = “select * from models”

rs.Open sSQL, dbs, adOpenDynamic, adLockOptimistic, -1

3) Запускаем цикл по ячейкам Excel и считываем их. Сохраняем поля name_m с ключевым полем IDm в таблицу models.

 

For j = 1 To rs.Fields.Count

i = 1

rs.MoveFirst

While Not rs.EOF

sSQL = “UPDATE models SET ” & _

“name_m = ‘” & Cells(i, 2) & “‘ WHERE IDm = ” & Cells(i, 1)

dbs.Execute (sSQL)

i = i + 1

rs.MoveNext

Wend

Next j

Set rs = Nothing

dbs.Close

72. У Вас есть таблицы ORDERS (поля: id_order, id_client, order_sum, order_data) и CLIENTS (поля id_client, name_client, family_client). В таблице ORDERS есть записи о заказах выполненных клиентами, данные о которых содержатся в таблице CLIENTS. Напишите SQL запрос выборки всех данных из таблицы ORDERS для клиента по фамилии «Иванов».

SELECT ORDERS.*

FROM CLIENTS INNER JOIN ORDERS ON CLIENTS.id_client = ORDERS.id_client

WHERE (((CLIENTS.family_client)=”Иванов”));

73. У Вас есть таблица SALES (поля id_ sale, sum_sale тип INTEGER, data_sale тип DATA). Поле id_ sale является автоинкрементным. Напишите запрос на вставку строки в таблицу SALES, в которой значение sum_sale = 1000 рублей, data_sale= 1.01.2010.

INSERT INTO SALES (sum_sale, data_sale)

VALUES (1000, “1.01.2010”);

 

74. Создайте с помощью DML команды CREATE TABLE таблицы ORDERS (поля: id_order, id_client, order_sum, order_data) и CLIENTS (поля id_cliens, name_client, family_client), так что бы они были связаны отношением один ко многим.

CREATE TABLE CLIENTS

(

id_client INTEGER NOT NULL,

name_client TEXT NOT NULL,

family_client TEXT NOT NULL

);

ALTER TABLE ORDERS

ADD PRIMARY KEY (id_client);

CREATE TABLE ORDERS

(

id_order INTEGER NOT NULL,

id_client INTEGER NOT NULL,

order_sum INTEGER DEFAULT NULL,

order_data DATE DEFAULT NULL

);

 

ALTER TABLE ORDERS

ADD PRIMARY KEY (id_order),

ADD FOREIGN KEY ORDERS_CLIENTS_fk (id_client) REFERENCES CLIENTS (id_client);

75. У Вас есть таблицы SALES (поля id_ sale, id_client, sum_sale) и CLIENTS (поля id_client, name_client, family_client). В таблице SALES (продажи) есть записи о продажах клиентам, перечень которых содержится в таблице CLIENTS (клиенты). Напишите SQL-запрос выборки клиента из таблицы CLENTS, продажи по которому максимальны. (Примеч. Можно использовать вложенные запросы).

SELECT CLIENTS.id_client, CLIENTS. name_client, CLIENTS. family_client, SALES.sum_sale

FROM CLIENTS INNER JOIN SALES ON CLIENTS.id_client=SALES.id_client

WHERE (((SALES.sum_sale)=(Select max(SALES.sum_sale) from SALES)));

76. У Вас есть таблица CLIENTS (поля id_client тип INTEGER, name_client тип STRING/VARCHAR, family_client тип STRING/VARCHAR). Напишите SQL –запрос, обеспечивающий обновление (UPDATE) значений полей name_client и family_client таблицы CLIENTS для id_client = 3 произвольными значениями (например, такими как: name_client = Петр, family_client = Иванов).

UPDATE CLIENTS

SET name_client=”Петр”, family_client=”Иванов”

WHERE id_client=3;

77. Создайте с помощью DML команды CREATE TABLE таблицу ORDERS (поля: id_order, id_client, order_sum, order_data), так что бы поле id_order было первичным ключом и автоинкрементным полем (Примеч. Предполагается, что используется СУБД MySQL, т.е. можно использовать атрибут AUTO_INCREMENT).

CREATE TABLE `orders` (

`id_order` INTEGER NOT NULL AUTO_INCREMENT,

`id_client` INTEGER(11) NOT NULL,

`order_sum` INTEGER(11) DEFAULT NULL,

`order_data` DATE DEFAULT NULL,

PRIMARY KEY (`id_order`)

)

78. У Вас есть таблицы GOODS (поля id_goods, name_goods, price_goods), ORDERS (id_order, id_client, id_goods) и CLIENTS (поля id_client, name_client, family_client). В таблице GOODS (товары) есть записи о товарах, заказываемых клиентами из таблицы CLIENTS (клиенты). Информация о заказах хранится в таблице ORDERS (заказы). Напишите SQL-запрос выборки товаров из таблицы GOODS, заказанных клиентом с id_client = 4. (Примеч. Можно использовать вложенные запросы).

SELECT GOODS.*

FROM GOODS INNER JOIN ORDERS ON GOODS.id_goods = ORDERS.id_goods

WHERE (([ORDERS].[id_client]=4));

79. У Вас есть таблица GOODS (поля id_goods, name_goods, price_goods). Напишите SQL –запрос, обеспечивающий удаление записей для id_goods = 8.

DELETE *

FROM GOODS

WHERE id_goods=8;

 

80. Создайте с помощью DML команды CREATE TABLE таблицы ORDERS (id_order, id_client, id_goods) и GOODS (поля id_goods, name_goods, price_goods), так что бы они были связаны отношением один ко многим.

CREATE TABLE ORDERS

(

id_order INTEGER NOT NULL,

id_client INTEGER NOT NULL,

id_goods INTEGER NOT NULL

);

ALTER TABLE ORDERS

ADD PRIMARY KEY (id_order);

CREATE TABLE GOODS

(

id_goods INTEGER NOT NULL,

name_goods TEXT,

price_goods INTEGER NULL

);

 

ALTER TABLE GOODS

ADD PRIMARY KEY (id_goods),

ADD FOREIGN KEY GOODS_ORDERS_fk (id_goods) REFERENCES CLIENTS (id_goods);

Шпаргалка по запросам и таблицам

Язык StructuredQueryLanguage — язык структурированных запросов, был создан Microsoft в конце 70-х годов и получил через некоторое время широкое распространение. Он позволяет формировать весьма сложные запросы к базам данных.

Запрос—это вопрос к базе данных, возвращающий запись или множество записей, удовлетворяющих запросу. Общие правила синтаксиса SQL очень просты. Язык SQL не чувствителен к регистру. Если используется программа из нескольких операторов SQL, то в конце каждого оператора ставится «;». Комментарий можно написать в стиле Си: /*<комментарий>*/, а в некоторых системах и в стиле Pascal: {<комментарий>}

Операторы SQL условно делятся на 2 подъязыка: DataDefinitionLanguage и DataManipulationLanguage.

DDL
CREATE TABLE <имя таблицы> (<имя столбца><тип данных>[NOT NULL]…) Создание новой таблицы PRIMARY KEY-указывает на то, что данное поле входит в первичный ключUNIQUE-значение этого поля должно быть уникальным и не может быть две записи с идентичными значениями таких полей

NOT NULL-значение этого поля должно быть обязательно задано в каждой записи

DEFAULT<значение>-значение поля по умолчанию

ALTER TABLE <имя таблицы> ({ADD, MODIFY, DROP}<имя столбца>[тип данных][NOT NULL]…) Изменение структуры таблицы ADD-добавить новый столбецDROP -удалить столбец

MODYFY-изменение столбца

DROP TABLE <имя таблицы> Удаление таблиц Тип данных не указывается
CREATE UNIQUE INDEX <имя индекса> ON <имя таблицы> (<имя столбца> [ASC/DESC]…) Создание индекса для одного или нескольких столбцов заданной таблицы с целью ускорения запросных и поисковых операция ASC-по возрастанию (идёт по умолчанию)DESC-по убыванию
DROP INDEX <имя индекса> Удаление индекса
CREATE VIEW <имя представления> [<имя столбца>…] AS <оператор SELECT> Создание представления Если имена столбцов не указывается, тогда будут использоваться имена столбцов из запроса, описываемого оператором SELECT.
DROP VIEW<имя представления>
GRANT и REVOKEоператоры управления правом доступа Оператор передачи прав на таблицу. По соображениям безопасности не каждому пользователю может быть разрешено получать информацию из какой-либо таблицы, а тем более изменять в ней данные. Для определения прав пользователей относительно объектов в БД в SQL определена пара команд: GRANT и REVOKE
GRANT ON <имя таблицы> [<список столбцов>] TO <имя пользователя> Тип прав на таблицу определяется следующими ключевыми словами:

  1. SELECT-право на получение информации
  2. UPDATE-изменение
  3. INSERT-добавление
  4. DELETE-удаление
  5. INDEX-индексирование
  6. ALTER-изменение схем в таблицах
  7. ALL-все права
REVOKE – то же самое, только отмена прав.
DML
SELECT Оператор возвращает одно или множество значений указанных полей записей, удовлетворяющих заданному условию и упорядоченных по заданному критерию.
SELECT [ALL/DISTINCT]<список данных> FROM <список таблиц> [WHERE<условия выборки>[GROUP BY

<имя столбца> [HAVING

<условие поиска>[ORDER BY

<спецификация>…]

После оператора FROM указываются имена таблиц, из которых производится выборка. Список данных включает имена столбцов, участвующих в запросе, а также выражения над столбцами, т.е. здесь можно записывать выражения, содержащие имена столбцов, знаки арифметических операций, константы, круглые скобки. Если выборка производится из нескольких таблиц, то для пояснения того, к какой таблице относится тот или иной столбец имя столбца записывается полностью: <имя таблицы>.<имя столбца> После оператора WHERE записываются условия, которым должны удовлетворять записи в результирующей таблице. Выражение условия выборки является логическим, в него могут входить имена столбцов, операции сравнения, арифметические операции, круглые скобки и некоторые специальные функции. Оператор GROUP BY позволяет выделить в результирующей таблице т.н. группы. К группе относятся записи с совпадающими значениями в столбцах, которые перечислены за словами GROUP BY. В выражении можно использовать групповые операции: ABG-среднее значение в группе, MAX-максимум, MIN-минимум, SUM-сумма, COUNT-число. Оператор HAVNG используется совместно с оператором GROUP BY для дополнительного отбора записей во время определения групп. Условие поиска строится по тем же правилам, что и выборка в WHERE. Оператор ORDER BY задает порядок сортировки записей в результирующей таблице [ORDER BY <имя столбца>[ASC/DESC]
UPDATE<имя таблицы> SET<имя столбца>= {<выражение>, NULL}… [WHERE <условие>] Оператор изменяет значения в столбцах таблицы, указанных после слова SET, для тех записей, которые удовлетворяют условию, записанному после оператора WHERE. Если новые значения в записи пустые, то пишется NULL, иначе вычисляются значения заданным выражением
INSERT INTO <имя таблицы> [(<список столбцов>)] VALUES (<список значений>) Оператор предназначен для ввода новых записей с заданными значениями в столбцах.
<предложение SELECT> Предназначается для ввода в заданную таблицу новых строк, выбранных из других таблиц с помощью предложения SELECT
DELETE FROM <имя таблицы> [WHERE<условие>]

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

Элементы реляционной модели.

Отношения

…— двумерная таблица, содержащая некоторые данные
Схема отношений …— строка заголовков столбцов таблицы; список имен атрибутов.
Кортеж …— строка таблицы.
Сущность …— объект любой природы, данные о к-ом хранятся в отношении; описание св-в объекта.
Атрибут …— свойства, характеризующие сущность; заголовок столбца таблицы.
Домен …— мн-во всех возмож. знач. опред. атрибута. Каждый домен образуют значение одного типа данных.
Значение атрибута …— значение поля в записи
Первичный  ключ …— атрибут отношения однозначно идентифицирующий каждый из его кортежей.
Тип данных …— тип значений элементов таблицы

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

Ключи обычно используют для достижения следующих целей. 1)Исключение дублирования значений в ключевых атрибутах 2)Упорядочение кортежей. П: по возрастанию или убыванию значений в ключевых атрибутах. 3)Ускорение работы с кортежами отношений. 4)Организация связывания таблиц

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

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

Правила (условия), при которых таблица является отношением:

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

2— Имена столбцов в таблице должны быть различны

3— Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.

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

Индексирование.

Термин индекс тесно связан с понятием «ключ». Индекс—это средство ускорения операции поиска записи в таблице -> и других операций, использующих поиск (извлечение, модификация, сортировка). Таблица, для которой используется индекс называется индексированной. Индекс выполняет роль оглавления таблицы, просмотру которого предшествует обращению к записям таблицы. В некоторых системах индексы хранятся в отдельных от таблиц файлах. Для быстрого поиска с помощью индексов обычно используют один из двух методов: последовательный и бинарный.

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

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

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

Между таблицами могут устанавливаться связи:

а) бинарные (между двумя);

б) тернарные (между тремя);

в) n-арные.

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

Существует 4 основных вида связи. 1:1 Образуется в случае, когда все поля связи основной и дополнительной таблиц являются ключевыми; поскольку значения в ключевых полях обеих таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Здесь таблицы равноправны. Сопоставление записей двух таблиц означает по существу образование новых «виртуальных» записей или псевдозаписей (). На практике это используется редко, т.к. хранимую в двух таблицах информацию легко объединить в одну таблицу, которая занимает гораздо меньше места, памяти ЭВМ.  … На практике в связь обычно вовлекается сразу несколько таблиц, при этом одна из таблиц может иметь различного рода связи с несколькими таблицами. Таким образом может образоваться иерархия или дерево связи.

Контроль целостности связи.

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

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

–     Каждой записи основной таблицы соответствует 0 или более записей дополнительной таблицы.

–     В дополнительной таблице нет записей, которые не имеют родительских записей в основной таблице

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

Рассмотрим контроль целостности при трёх основных операциях:

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

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

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

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

3.Удаление записей. Основная таблица подчиняется одному из следующих правил:

а) Удалять можно запись, которая не имеет подчиненных записей

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

Pin It on Pinterest

Яндекс.Метрика