Читайте также:
|
Исключительные ситуации, возникающие при работе программы, можно разделить на два основных типа: синхронные и асинхронные, принципы реакции на которые существенно различаются.
§ Синхронные исключения могут возникнуть только в определённых, заранее известных точках программы. Так, ошибка чтения файла или коммуникационного канала, нехватка памяти — типичные синхронные исключения, так как возникают они только в операции чтения из файла или из канала или в операции выделения памяти соответственно.
§ Асинхронные исключения могут возникать в любой момент времени и не зависят от того, какую конкретно инструкцию программы выполняет система. Типичные примеры таких исключений: аварийный отказ питания или поступление новых данных.
Некоторые типы ошибок могут быть отнесены как к синхронным, так и к асинхронным. Например, инструкция деления на нуль на многих программно-аппаратных платформах приводит к синхронному исключению, но на некоторых платформах за счёт глубокой конвейеризации исключение может оказаться асинхронным.
Существует два принципиально разных механизма функционирования обработчиков исключений.
§ Обработка с возвратом подразумевает, что обработчик исключения ликвидирует возникшую проблему и приводит программу в состояние, когда она может работать дальше по основному алгоритму. В этом случае после того, как выполнится код обработчика, управление передаётся обратно в ту точку программы, где возникла исключительная ситуация (либо на команду, вызвавшую исключение, либо на следующую за ней, как в некоторых старых диалектах языка BASIC) и выполнение программы продолжается. Обработка с возвратом типична для обработчиков асинхронных исключений (которые обычно возникают по причинам, не связанным прямо с выполняемым кодом), для обработки синхронных исключений она малопригодна.
§ Обработка без возврата заключается в том, что после выполнения кода обработчика исключения управление передаётся в некоторое, заранее заданное место программы, и с него продолжается исполнение.
§ В целом, обработка исключений может выглядеть следующим образом (в некотором абстрактном языке):
§ try {§ line = console.readLine();§ if (line.length() == 0)§ throw new EmptyLineException("Строка, считанная с консоли, пустая!");§ § console.printLine("Привет, %s!" % line);§ }§ catch (EmptyLineException exception) {§ console.printLine("Привет!");§ }§ catch (Exception exception) {§ console.printLine("Ошибка: " + exception.message());§ }§ else {§ console.printLine("Программа выполнилась без исключительных ситуаций");§ }§ finally {§ console.printLine("Программа завершается");§ }
14. Шаблони проектування. Породження об’єктів. Приклади реалізації на об’єктно-орієнтованій мові програмування.
В разработке программного обеспечения, шаблон проектирования или паттерн (англ. design pattern) — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.
Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться.
«Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные.
На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.
Алгоритмы по своей сути также являются шаблонами, но не проектирования, а вычисления, так как решают вычислительные задачи.
Порождающие шаблоны (англ. Creational patterns) — шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту.
| Абстрактная фабрика | Abstract factory | Класс, который представляет собой интерфейс для создания компонентов системы. | Да |
| Строитель | Builder | Класс, который представляет собой интерфейс для создания сложного объекта | Да |
| Фабричный метод | Factory method | Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанциировать | Да |
| Отложенная инициализация | Lazy initialization | Объект, инициализируемый во время первого обращения к нему | Нет |
| Пул одиночек | Multiton | Гарантирует, что класс имеет поименованные экземпляры объекта и обеспечивает глобальную точку доступа к ним | Нет |
| Объектный пул | Object pool | Класс, который представляет собой интерфейс для работы с набором инициализированных и готовых к использованию объектов | Нет |
| Прототип | Prototype | Определяет интерфейс создания объекта через клонирование другого объекта вместо создания через конструктор | Да |
| Получение ресурса есть инициализация | Resource acquisition is initialization (RAII) | Получение некоторого ресурса совмещается с инициализацией, а освобождение — с уничтожением объекта | Нет |
| Одиночка | Singleton | Класс, который может иметь только один экземпляр. |
Шаблон проектирования “Абстрактная фабрика”, пример реализации на С++
AbstractFactory (WidgetFactory) - абстрактная фабрика:
объявляет интерфейс для операций, создающих абстрактные объекты-продукты;
система не должна зависеть от того, как создаются, компонуются и представляются входящие в нее объекты
входящие в семейство взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения;
система должна конфигурироваться одним из семейств составляющих ее объектов;
вы хотите предоставить библиотеку объектов, раскрывая только их интерфейсы, но не реализацию.
class MazeFactory {
public:
MazeFactory();
virtual Maze* MakeMazeO const
{ return new Maze; }
virtual Wall* MakeWalK) const
{ return new Wall; }
virtual Room* MakeRoom(int n) const
{ return new Room(n); }
virtual Door* MakeDoor(Room* rl, Room* r2) const
{ return new Door(rl, r2); }
};
15. Шаблони проектування. Розподіл обов’язків між класами та з використанням шаблонів поведінки. Приклади реалізації на об’єктно-орієнтованій мові програмування.
В разработке программного обеспечения, шаблон проектирования или паттерн (англ. design pattern) — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.
Поведенческие шаблоны (Behavioral) определяют взаимодействие между объектами, увеличивая таким образом его гибкость.
В поведенческих шаблонах уровня класса используется наследование, чтобы определить поведение для различных классов. В поведенческих шаблонах уровня объекта используется композиция. Некоторые из них описывают, как с помощью кооперации несколько равноправных объектов работают над заданием, которое они не могут выполнить по отдельности. Здесь важно то, как объекты получают информацию о существовании друг друга. Объекты-коллеги могут хранить ссылки друг на друга, но это усиливает степень связанности системы. При высокой связанности каждому объекту пришлось бы иметь информацию обо всех остальных. Некоторые из шаблонов решают эту проблему.
| Цепочка ответственности | Chain of responsibility | Предназначен для организации в системе уровней ответственности | Да |
| Команда, Action, Transaction | Command | Представляет действие. Объект команды заключает в себе само действие и его параметры | Да |
| Интерпретатор | Interpreter | Решает часто встречающуюся, но подверженную изменениям, задачу | Да |
| Итератор, Cursor | Iterator | Представляет собой объект, позволяющий получить последовательный доступ к элементам объекта-агрегата без использования описаний каждого из объектов, входящий в состав агрегации | Да |
| Посредник | Mediator | Обеспечивает взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга | Да |
| Хранитель, Token | Memento | Позволяет не нарушая инкапсуляцию зафиксировать и сохранить внутреннее состояния объекта так, чтобы позднее восстановить его в этом состоянии | Да |
| Null object | Предотвращает нулевые указатели, предоставляя объект «по умолчанию» | Нет | |
| Наблюдатель, Dependents, Publish-Subscribe, Listener | Observer илиPublish/subscribe | Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии | Да |
| Слуга | Servant | Используется для обеспечения общей функциональности группе классов | Нет |
| Specification | Служит для связывания бизнес-логики | Нет | |
| Состояние, Objects for States | State | Используется в тех случаях, когда во время выполнения программы объект должен менять свое поведение в зависимости от своего состояния | Да |
| Стратегия | Strategy | Предназначен для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости | Да |
| Шаблонный метод | Template method | Определяет основу алгоритма и позволяет наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом. | Да |
| Посетитель | Visitor | Описывает операцию, которая выполняется над объектами других классов. При изменении класса Visitor нет необходимости изменять обслуживаемые классы. | Да |
| Simple Policy | Нет | ||
| Event listener | Нет | ||
| Single-serving visitor | Single-serving visitor | Оптимизирует реализацию шаблона посетитель, который инициализируется, единожды используется, и затем удаляется | Нет |
| Hierarchical visitor | Hierarchical visitor | Предоставляет способ обхода всех вершин иерархической структуры данных (напр. древовидной) |
Шаблон проектирования “Хранитель”, пример реализации на С++
необходимо сохранить мгновенный снимок состояния объекта (или его части), чтобы впоследствии объект можно было восстановить в том же состоянии;
прямое получение этого состояния раскрывает детали реализации и нарушает инкапсуляцию объекта;
не нарушая инкапсуляции, фиксирует и выносит за пределы объекта его внутреннее состояние так, чтобы позднее можно было восстановить в нем объект.
class Graphic;
// базовый класс графических объектов
class MoveCoitimand {
public:
MoveCommand (Graphic* target, const Point& delta);
void Execute ();
void Unexecute ();
private:
ConstraintSolverMemento* _state;
Point _delta;
Graphic* _target;
};
16. Якість програмних систем. Оцінювання якості людино-машинного інтерфейсу.
Якість ПС – це відносне поняття, що має сенс тільки з урахуванням реальних умов його застосування, тому вимоги до якості висуваються відповідно до умов та конкретної сфери їхнього використання. Якість характеризується трьома аспектами: якість програмного продукту, якість процесів ЖЦ й якість супроводу або впровадження (рис. 9.1).
Рис. 9.1. Основні аспекти якості ПС
Аспект, пов'язаний із процесами ЖЦ, визначає ступінь формалізації, вірогідності процесів ЖЦ з розроблення ПС, а також верифікацію й валідацію проміжних і кінцевих результатів на цих процесах. Пошук й усунення помилок у готовому ПС проводиться за допомогою методів тестування, які зменшують кількість помилок і підвищують якість цього продукту.
Якість продукту досягається процедурами контролю проміжних продуктів під час процесів ЖЦ, перевіркою їх на досягнення необхідної якості, а також методами супроводу продукту. Ефект від впровадження ПС великою мірою залежить від знань обслуговуючого персоналу функцій продукту й правил їхнього виконання.
Модель якості програмного забезпечення (рис. 9.2) має чотири рівні подання.
Перший рівень подання відповідає визначенню характеристик (показників) якості ПС, кожна з яких відображає окреме уявлення користувача про якість.
Відповідно до стандарту [1–4] у модель якості входить шість характеристик або шість показників якості:
1) функціональність (functionality);
2) надійність (realibility);
3) зручність (usability);
4) ефективність (efficiency);
5) супровід (maitainnability);
6) мобільність (portability).
Другому рівню подання відповідають атрибути для кожної характеристики якості, які деталізують різні аспекти конкретної характеристики. Набір атрибутів характеристик якості використовується для оцінки якості.
Третій рівень подання призначено для виміру якості за допомогою метрик, кожна з яких відповідно до стандарту [1] визначається як комбінація методу виміру атрибута й шкали виміру значень атрибутів. Для оцінки атрибутів якості на процесах ЖЦ (при перегляді документації, програм і результатів тестування програм) використовуються метрики із заданою цінною вагою для нівелювання результатів метричного аналізу сукупних атрибутів конкретного показника і якості в цілому. Атрибут якості визначається за допомогою однієї або декількох методик оцінки на процесах ЖЦ і на завершальному процесі розроблення ПС.
Четвертий рівень подання – це оцінний елемент метрики (вага), що використовується для оцінки кількісного або якісного значення окремого атрибута показника ПС. Залежно від призначення, особливостей та умов супроводу вибираються найважливі характеристики якості та їхні атрибути.
Рис. 9.2. Модель характеристик якості
Вибрані атрибути та їхні пріоритети відображаються у вимогах на розробку систем або використовуються відповідні пріоритети еталона класу ПС, до якого це ПС належить.
Человеко-машинный интерфейс (ЧМИ) (англ. Human machine interface, HMI) — широкое понятие, охватывающее инженерные решения, обеспечивающие взаимодействие человека-оператора с управляемыми им машинами.
Создание систем человеко-машинного интерфейса тесно увязано с понятиями эргономика и юзабилити.
Проектирование ЧМИ включает в себя:
§ создание рабочего места: кресла, стола, или пульта управления, размещение приборов и органов управления (соответствием всего этого физиологии человека занимается эргономика), освещение рабочего места и, возможно, микроклимат[ источник не указан 159 дней ].
§ далее рассматриваются взаимодействие оператора со всеми органами управления: их доступность и необходимые усилия, эффективность и скорость доступа, согласованность (непротиворечивость) управляющих воздействий (в том числе т. н. «защита от дурака»), расположение дисплеев и размеры надписей на них (всё это входит в сферу юзабилити)
Одной из наиболее сложных задач является создание эффективного ЧМИ рабочих мест сложных машин с множеством органов управления, например пилотов самолёта икосмических кораблей.
В промышленных условиях ЧМИ чаще всего реализуется с использованием типовых средств: операторских панелей, компьютеров и типового программного обеспечения.
17. Якість програмних систем. Типи вимог, функціональні, не функціональні, атрибути якості.
Якість ПС – це відносне поняття, що має сенс тільки з урахуванням реальних умов його застосування, тому вимоги до якості висуваються відповідно до умов та конкретної сфери їхнього використання. Якість характеризується трьома аспектами: якість програмного продукту, якість процесів ЖЦ й якість супроводу або впровадження (рис. 9.1).
Рис. 9.1. Основні аспекти якості ПС
Аспект, пов'язаний із процесами ЖЦ, визначає ступінь формалізації, вірогідності процесів ЖЦ з розроблення ПС, а також верифікацію й валідацію проміжних і кінцевих результатів на цих процесах. Пошук й усунення помилок у готовому ПС проводиться за допомогою методів тестування, які зменшують кількість помилок і підвищують якість цього продукту.
Якість продукту досягається процедурами контролю проміжних продуктів під час процесів ЖЦ, перевіркою їх на досягнення необхідної якості, а також методами супроводу продукту. Ефект від впровадження ПС великою мірою залежить від знань обслуговуючого персоналу функцій продукту й правил їхнього виконання.
Модель якості програмного забезпечення (рис. 9.2) має чотири рівні подання.
Перший рівень подання відповідає визначенню характеристик (показників) якості ПС, кожна з яких відображає окреме уявлення користувача про якість.
Відповідно до стандарту [1–4] у модель якості входить шість характеристик або шість показників якості:
1) функціональність (functionality);
2) надійність (realibility);
3) зручність (usability);
4) ефективність (efficiency);
5) супровід (maitainnability);
6) мобільність (portability).
Другому рівню подання відповідають атрибути для кожної характеристики якості, які деталізують різні аспекти конкретної характеристики. Набір атрибутів характеристик якості використовується для оцінки якості.
Третій рівень подання призначено для виміру якості за допомогою метрик, кожна з яких відповідно до стандарту [1] визначається як комбінація методу виміру атрибута й шкали виміру значень атрибутів. Для оцінки атрибутів якості на процесах ЖЦ (при перегляді документації, програм і результатів тестування програм) використовуються метрики із заданою цінною вагою для нівелювання результатів метричного аналізу сукупних атрибутів конкретного показника і якості в цілому. Атрибут якості визначається за допомогою однієї або декількох методик оцінки на процесах ЖЦ і на завершальному процесі розроблення ПС.
Четвертий рівень подання – це оцінний елемент метрики (вага), що використовується для оцінки кількісного або якісного значення окремого атрибута показника ПС. Залежно від призначення, особливостей та умов супроводу вибираються найважливі характеристики якості та їхні атрибути.
Рис. 9.2. Модель характеристик якості
18. Якість програмних систем. Тестування. Приклад автоматизованого тесту.
Тестирование применяется для определения соответствия предмета испытания заданным спецификациям. В задачи тестирования не входит определение причин несоответствия заданным требованиям (спецификациям). Тестирование — один из разделов диагностики.
Тестирование применяется в технике, медицине, психиатрии, образовании для определения пригодности объекта тестирования для выполнения тех или иных функций. Качество тестирования и достоверность его результатов в значительной степени зависит от тестировщика.
Технология тестирования состоит из следующих частей:
§ внешнее воздействие;
§ реакция испытуемого;
§ оценка реакции и выводы.
Испытания проводятся многократно, при разных внешних воздействиях, до тех пор, пока тестер не сможет принять решение о пригодности испытуемого к реализации заданных функций.
В технической диагностике(цифровые устройства) применяются формализованные методы разработки минимальных, необходимых и достаточных тестов проверки работоспособности (соответствия спецификациям). Недостатком формальных методов разработки тестов цифровых устройств является использование модели статических неисправностей (обрыв, короткое замыкание, и т. п.).
Автоматизированное тестирование программного обеспечения — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
Первые попытки «автоматизации» появились в эпоху операционных систем DOS и CP/M. Тогда она заключалась в выдаче приложению команд через командную строку и анализе результатов. Чуть позднее добавились удаленные вызовы через API для работы по сети. Впервые об автоматизированном тестировании упоминается в книгеФредерика Брукса «Мифический человеко-месяц», где говорится о перспективах использования модульного тестирования. Но по-настоящему автоматизация тестирования стала развиваться только в 1980-х годах.
Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и GUI-тестирование. К первому типу относится, в частности, модульное тестирование. Ко второму — имитация действий пользователя с помощью специальных тестовых фреймворков.
Наиболее распространенной формой автоматизации является тестирование приложений через графический пользовательский интерфейс. Популярность такого вида тестирования объясняется двумя факторами: во-первых, приложение тестируется тем же способом, которым его будет использовать человек, во-вторых, можно тестировать приложение, не имея при этом доступа к исходному коду.
Одной из главных проблем автоматизированного тестирования является его трудоемкость: несмотря на то, что оно позволяет устранить часть рутинных операций и ускорить выполнение тестов, большие ресурсы могут тратиться на обновление самих тестов. Это относится к обоим видам автоматизации. При рефакторинге часто бывает необходимо обновить и модульные тесты, и изменение кода тестов может занять столько же времени, сколько и изменение основного кода. С другой стороны, при изменении интерфейса приложения необходимо заново переписать все тесты, которые связаны с обновленными окнами, что при большом количестве тестов может отнять значительные ресурсы.
19. Нотації та засоби підтримки проектування. Описи статичної моделі з використанням UML. Приклади діаграм класів та об’єктів.
Под средствами проектирования информационных систем (СП ИС) будем понимать комплекс инструментальных средств, обеспечивающих в рамках выбранной методологии проектирования поддержку полного жизненного цикла (ЖЦ) ИС, который включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. Каждый этап характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. При анализе СП их следует рассматривать не локально, а в комплексе, что позволяет реально охарактеризовать их достоинства, недостатки и место в общем технологическом цикле создания ИС.
В общем случае стратегия выбора СП для конкретного применения зависит от следующих факторов:
Статическая модель включает в себя три области: обязанности, атрибуты и отношения. При проектировании статической модели главным принципом является следующий: В обязанности каждого класса входит решение только одной задачи!
Это не значит, что в классе должен быть всего один метод, просто все методы класса должны быть согласованы и повышать способность класса решать поставленную перед ним задачу.
Диаграмма классов (Static Structure diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
§ концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
§ точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
§ точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
§ 
20. Нотації та засоби підтримки проектування. Описи динамічної моделі з використанням UML. Приклади діаграм послідовностей.
Под средствами проектирования информационных систем (СП ИС) будем понимать комплекс инструментальных средств, обеспечивающих в рамках выбранной методологии проектирования поддержку полного жизненного цикла (ЖЦ) ИС, который включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. Каждый этап характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. При анализе СП их следует рассматривать не локально, а в комплексе, что позволяет реально охарактеризовать их достоинства, недостатки и место в общем технологическом цикле создания ИС.
В общем случае стратегия выбора СП для конкретного применения зависит от следующих факторов:
Динамическая модель - теоретическая конструкция (модель), описывающая изменение (динамику) состояний объекта. Динамическая модель может включать в себя описание этапов или фаз[1] или диаграмму состояний подсистем[2]. Часто имеет математическое выражение[3] и используется главным образом в общественных науках(например, в социологии[4]), имеющих дело с динамическими системами, однако современная парадигма науки способствует тому, что данная модель также имеет широкое распространение во всех без исключения науках в т.ч. в естественных[5] и технических[6].
Диаграмма последовательности (англ. sequence diagram ) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.
Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.
2. Мова XML. Визначення схеми документу за допомогою XSD. Приклад схеми та документу, що задовольняє цій схемі. Приклад програмної валідації XML документу.
Можно создавать представления схем XML реляционных данных при помощи языка XSD. Затем можно выполнять запросы к этим представлениям при помощи языка XPath (XML Path). Это аналогично созданию представлений с помощью инструкции CREATE VIEW с последующим указанием запросов SQL к представлению.
Схема XML описывает структуру XML-документа, а также описывает различные ограничения на данные, содержащиеся в документе. При задании запросов XPath по схеме структура возвращаемого XML-документа определяется согласно схеме, по которой выполняется запрос XPath.
В схеме XSD элемент <xsd:schema> заключает в себе схему; все схемы элементов должны содержаться в элементе <xsd:schema>. Можно описывать атрибуты, определяющие пространство имен, в котором находится схема, и пространства имен, используемые в схеме, как свойства элемента <xsd:schema>.
Правильная схема XSD должна содержать элемент <xsd:schema>, определенный следующим образом:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sql="urn:schemas-microsoft-com:mapping-schema">
<!-- additional schema definitions here -->
</xsd:schema>
2. Об’єкти реляційної бази даних. Їх створення та модифікація засобами SQL. Приклад реалізації за допомогою Data Definition Language.
База данных состоит из различных объектов, таких как таблицы, виды, домены, сохраненные процедуры, триггеры. Объекты базы данных содержат всю информацию о ее структуре и данных. Объекты базы данных так же упоминаются, как метаданные.
Таблицы (Tables)
Реляционные базы данных хранят все данные в таблицах. Таблица это структура, состоящая из множества неупорядоченных горизонтальных строк (rows), каждая из которых содержит одинаковое количество вертикальных столбцов (colums). Пересечение отдельной строки и столбца называеися полем (field), которое содержит специфическую информацию. Многие принципы работы реляционной базы данных взяты из определений отношений (relations) между таблицами.
InterBase хранит информацию о метаданных в специальных таблицах, которые называются системными таблицами (system tables). Системные таблицы имеют специальные столбцы, которые содержат информацию о типе метаданных в этой таблице. Имена всех системных таблиц начинаются с «RDB$». Пример системной таблицы – RDB$RELATIONS, которая содержит информацию о каждой таблице в базе данных.
Системные таблицы имеют такую же структуру, как и определенные пользователем таблицы и расположенны в той же самой базе. Так как метаданные, пользовательские таблицы, и данные все вместе расположены в одном и том же файле базы данных, каждая база данных является законченным модулем и может быть легко перенесена между различными машинами.
Системные таблицы могут быть изменены подобно любой другой таблице базы данных. Если вы не понимаете всех взаимосвязей между системными таблицами, то непосредственное изменение их может иметь негативный эффект на другие системные таблицы и разрушить вашу базу данных.
Столбцы (Columns)
Создание таблицы главным образом подразумевает определение столбцов таблицы. Главные атрибуты столбца включают:
Типы данных (Data types)
Данные сохранены в определенном формате, который называется типом данных (data type). Типы данных могут быть классифицированы по четырем категориям: числовые (numeric), символьные (character), даты (date) и BLOB. Числовые данные включают в себя все числа, начиная с целых вплоть до чисел двойной точности с плавающей точкой. Символьные данные содержат строки текста. Даты используются для хранения дат и времени.
В то время как числовые, символьные и даты являются стандартными типами данных, BLOB-тип заслуживает специального внимания.
Тип данных BLOB
InterBase поддерживает такой тип данных, как большие бинарные объекты (binary large object – BLOB), которые могут хранить данные неограниченного размера. Тип BLOB это расширение стандартной реляционной модели, которая обычно обеспечивает только типы данных фиксированной длины.
Тип данных BLOB аналогичен последовательному файлу (flat file), BLOB данные могут быть сохранены в любом формате (к примеру, бинарном или ASCII). BLOB, однако, это не отдельный файл. BLOB данные хранятся в базе данных наряду со всеми другими данными. Так как BLOB столбцы часто содержат большие и переменные объемы данных, BLOB столбцы хранятся в отдельных сегментах.
InterBase не поддерживает непосредственно преобразование BLOB данных в другие форматы, но на некоторых платформах, BLOB фильтры могут транслировать BLOB данные из одного формата в другой.
Домены (Domains)
В добавление к явному определению типа данных столбцов, InterBase обеспечивает глобальные определения столбцов или домены (domains), на которых могут базироваться определения столбцов. Домен содержит информацию о тип данных, устанавливает атрибуты и ограничения целостности столбцов. В последующем при создании таблиц возможно использовать домены для определения столбцов.
Справочные ограничения целостности (Referential integrity constraints)
InterBase позволяет вам определять правила обеспечивающие целостность информации хранящейся в столбцах, эти првавила названы справочными ограничениями целостности (referential integrity constraints). Ограничения целостности управляют связями типа столбец-таблица (column-to-table) и таблица-таблица (table-to-table) а также проверкой ввода данных. Они выпонены через первичные ключи (primary keys), внешние ключи (foreign keys) и проверочные ограничения (check constraints). Обычно первичный ключ это столбец (или группа столбцов), которые используются, чтобы уникально идентифицировать строку таблицы. Внешний ключ это столбец, чьи значения должны соответствовать значениям столбца в другой таблице. Проверочные ограничения – ограничивают ввод данных определенным диапазоном или набором значений.
Например, таблица EMPLOYEE могла бы быть определена имеющей внешний ключ столбец DEPT_NO. Который определен в соответствии со столбцом номера отдела в таблице DEPARTMENT. Это гарантировало бы, что каждый служащий из таблицы EMPLOYEE связан с существующим отделом в таблице DEPARTMENT.
Индексы (Indexes)
Индексы это механизм для улучшения быстродействия поиска данных. Индекс определяет столбцы которые могут быть использованы для эффективного поиска и сортировки в таблице.
InterBase автоматически определят уникальные индексы для первичных и внешних ключей таблицы.
Виды (Views)
Вид (view) это виртуальная таблица, которая не сохранена физически в базе данных, но ведет себя точно также как «реальная» таблица. Вид может содержать данные из одной или более таблиц или других видов и используется для хранения часто используемых запросов (queries) или множества запросов в базе данных.
Виды могут также обеспечивать ограниченные средства защиты, так как они могут обеспечивать доступ пользователей к подмножеству доступных данных при скрытии других связанных и чувствительных данных.
Сохраненные процедуры (Stored procedures)
Сохраненные процедуры (stored procedure) это отдельные программы, написанные на языке процедур и триггеров InterBase, который является расширением SQL. Сохраненные процедуры являются частью метаданных базы данных. Сохраненные процедуры могут получать входные параметры, возвращать значения приложению и могут быть вызваны явно из приложения или подстановкой вместо имени таблицы в инструкции SELECT.
Сохраненные процедуры обеспечивают следующие возможности:
Триггеры (Triggers)
Триггеры это отдельная программа, ассоциированная с таблицей или видом, которая автоматически выполняет действия, при добавлений, изменений или удалений строки в таблице или виде.
Триггеры могут обеспечивать следующие возможности:
Когда триггер вызван, он имеет непосредвенный доступ к добавлению, изменению или уничтожению данных. Триггеру могут быть так же доступны данные из других таблиц. Вы можете разрабатывать триггеры для:
Генераторы (Generators)
Генератор (generator) это механизм который создает последовательный уникальный номер, который автоматически вставляется в столбец базой данных, когда выполняются операции INSERT или UPDATE. Генератор обычно применяется для создания уникальных значений, вставляемых в столбец, который используется как PRIMARY KEY. Для базы данных может быть определено любое число генераторов, каждый генератор должен имеет уникальное имя.
Защита (Security)
SQL защита (securite) управляется на уровне таблицы привилегий доступа – списка операций, которые разрешены пользователю над данной таблицей или видом. Инструкция GRANT назначает привилегии доступа к таблице или виду конкретным пользователям или процедурам. Инструкция REVOKE удаляет предварительно предоставленные привилегии доступа.
Data Definition Language (DDL) (язык описания данных) — это семейство компьютерных языков, используемых в компьютерных программах для описания структуры баз данных.
На текущий момент наиболее популярным языком DDL является SQL, используемый для получения и манипулирования данными в РСУБД, и сочетающий в себе элементы DDL, DML и DCL.
Функции языков DDL определяются первым словом в предложении (часто называемом запросом), которое почти всегда является глаголом. В случае с SQL эти глаголы — «create» («создать»), «alter» («изменить»), «drop» («удалить»). Это превращает природу языка в ряд обязательных утверждений (команд) к базе данных.
Языки DDL могут существенно различаться у различных производителей СУБД. Существует ряд стандартов SQL, установленный ISO/IEC (SQL-89,SQL-92, SQL:1999, SQL:2003, SQL:2008), но производители СУБД часто предлагают свои собственные «расширения» языка и, часто, не поддерживают стандарт полностью.
2 билет
·
2. Витяг даних з кількох таблиць. Приклади використання INNER JOIN, LEFT(RIGHT) OUTER JOIN, EXISTS, ANY.
Синтаксис оператора SELECT для выполнения операции внутреннего объединения имеет вид:
SELECT [DISTINCT] [<table1>.]<column_name>, [<table2>.]<column_name> [,...]
FROM <table1> [INNER] JOIN <table2> [таблица_1.]
ON <column_name><join_condition>...][таблица_2.]<column_name>
Оператор SELECT здесь точно такой же, как и при использовании предложения WHERE, но предложение FROM другое. Здесь отношение между двумя таблицами является частью предложения FROM, указанного как INNER JOIN. При использовании такого синтаксиса предложение объединения указывается с использованием специального предложения ON вместо предложения WHERE. Фактическое предложение, передаваемое в ON, то же самое, которое передавалось бы в предложение WHERE*.
Ниже представлены запросы из предыдущего раздела, написанные с применением INNER JOIN.
Подсчитать количество договоров, заключенных на пользование каждой из предлагаемых услуг. Полученный список отсортировать по названию услуги.
SQL:
SELECT service, СOUNT(contract_id)
ROM tbl_service
INNER JOIN tbl_contract ON tbl_service.service_id = tbl_contract.service_id
WHERE retire_date IS NULL
GROUP BY service
1.
2. Обмеження реляційної бази даних. Їх створення та модифікація засобами SQL. Приклад реалізації Data Definition Language.
Дата добавления: 2015-11-16; просмотров: 68 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Итераторы вывода | | | Недостатки реляционных СУБД |