ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 21.01.2025
Просмотров: 2231
Скачиваний: 3
СОДЕРЖАНИЕ
8. Типы структур ис. Их характеристики, достоиства, недостатки.
3. Клиент серверная архитектура.
9. Определение реляционной модели данных, характеристика ее основных элементов.
10. Основные подходы к проектированию структур данных и проблемы определения структур данных.
14. Формирование отношений для связи 1:м при кп обязательном для м связной сущности.
15. Формирование отношений для связи 1:м при кп необязательном для м-связной сущности.
16. Формирование отношений для связи м:м.
17. Этапы проектирования и назначение диаграммы er-экземпляров и er-типа.
18. Фильтрация записей. Фильтрация по выражению.
19. Фильтрация записей. Фильтрация по диапазону.
21. Схема взаимодействия компонентов при проектировании бд в Delphi.
Связь этих компонентов друг с другом и с базой данных можно представить схемой приведенной ниже:
22. Основные этапы создания приложения бд в Delphi.
23. Назначение компонента tDataSource в создании бд. Основные свойства и методы компонента.
24. Назначение компонента тТablе в создании бд. Основные свойства и методы компонента.
25. Приёмы работы с набором данных(нд). Состояния набора данных. Метод State.
28. Назначение компонента tdbGrid в создании бд. Основные свойства и методы компонента.
30. Методы поиска записей в наборе данных. Метод Locate.
31. Методы поиска записей в наборе данных. Метод Lookup.
32. Методы поиска записей в наборе данных. Методы FindKey и FindNearest(инкрементный поиск записей).
33. Отображение и редактирование данных. Классификация компонентов отображения данных.
34. Назначение компонента tQuery- Основные свойства и методы.
36.Основные операторы языка sql. Оператор select: назначение, формат оператора.
38. Использование оператора select для сортировки нд и устранения повторяющихся значений.
39. Использование оператора select для расчета вычисляемых столбцов и группировки записей.
41. Использование оператора select для внешнего соединения. Формат запроса.
42. Операторы insert, delete, update. Форматы операторов и назначение.
43. Ссылочная целостность таблиц бд и механизмы ее осуществления. Понятие транзакции.
46. Использование bde Administrator при создании бд.
47. Роль индексов в субд. Определение индексов. Связывание таблиц бд.
48. Работа с визуальным компонентом tdbGrid и настройка полей таблиц.
49. Навигация по набору данных. Использование визуального компонента tdbNavigator.
50. Создание поля просмотра и вычисляемого поля. Основные проблемы и пути их решения.
Функции СУБД (назначение и возможности)
1. Хранение, извлечение и обновление данных. СУБД должна предоставлять пользователям возможность сохранять, извлекать и обновлять данные в базе данных. Это самая фундаментальная функция СУБД. Причем, способ реализации этой функции должен быть скрыт от конечного пользователя.
2. Каталог, доступный конечным пользователям. СУБД должна иметь доступный конечным пользователям каталог, в котором хранится описание элементов данных. Ключевой особенностью архитектуры ANSI/SPARC является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т. д. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. Системный каталог или словарь данных является хранилищем информации, описывающей данные в базе данных (метаданные). В зависимости от типа используемой СУБД количество информации и способ ее применения могут варьироваться. Обычно в системном каталоге хранятся следующие сведения:
- имена, типы и размеры элементов данных;
- имена связей;
- накладываемые на данные ограничения поддержки целостности;
- имена санкционированных пользователей;
- внешняя, концептуальная и внутренняя схемы и отображения между ними;
- статистические данные (частота транзакций, счетчик обращения к объектам базы данных).
Системный каталог позволяет достичь определенных преимуществ:
- информация о данных может быть централизованно собрана и сохранена, что позволит контролировать доступ к этим данным, как и к любому другому ресурсу;
- можно определить смысл данных, что поможет другим пользователям понять их назначение;
- упрощается сообщение, так как сохраняются точные определения смысла данных. В системном каталоге также могут быть указаны один или несколько пользователей, которые являются владельцами данных или обладают правом доступа к ним;
- благодаря централизованному хранению избыточность и противоречивость описания отдельных элементов данных могут быть легко обнаружены;
- внесенные в базу данных изменения могут быть запротоколированы;
- последствия любых изменений могут быть определены еще до их внесения, поскольку в системном каталоге зафиксированы все существующие элементы данных, установленные между ними связи, а также все их пользователи;
- меры обеспечения безопасности могут быть дополнительно усилены;
- появляются новые возможности организации поддержки целостности данных;
- может выполняться аудит сохраняемой информации.
3. Поддержка транзакций. СУБД должна иметь механизм, который гарантирует выполнение либо всех операций обновления данной транзакции, либо ни одной из них. Транзакция представляет собой набор действий, выполняемых отдельным пользователем или прикладной программой с целью доступа или изменения содержимого базы данных (например, удаление сведений о сотруднике из база данных и передача ответственности за всю курируемую им работу другому сотруднику). Если во время выполнения транзакции произойдет сбой, например, из-за выхода из строя компьютера, база данных попадет в противоречивое состояние, поскольку некоторые изменения уже будут внесены, а остальные – нет. В этом случае все частичные изменения должны быть отменены для возвращения базы данных в исходное непротиворечивое состояние.
4. Сервисы управления параллельностью. СУБД должны иметь механизм, который гарантирует корректное обновление базы данных при параллельном выполнении операций обновления многими пользователями. Одна из основных целей создания и использования СУБД заключается в том, чтобы множество пользователей могло осуществлять доступ к совместно обрабатываемым данным. Параллельный доступ сравнительно просто организовать, если все пользователи выполняют только чтение данных. Конфликтные ситуации с нежелательными последствиями легко могут возникнуть, когда два и более пользователей пытаются обновить данные. СУБД должна гарантировать, что при одновременном доступе к базе данных многих пользователей таких конфликтов не произойдет.
5. Сервисы восстановления. СУБД должна предоставлять средства восстановления базы данных на случай какого-либо ее повреждения или разрушения. Сбой может произойти в результате выхода из строя системы или запоминающего устройства, возможны ошибки аппаратного и программного обеспечения, которые могут привести к останову СУБД. К тому же пользователь может потребовать отмены операции. Во всех подобных случаях СУБД должна предоставить механизм восстановления базы данных и возврата к ее непротиворечивому состоянию. Сервисы восстановления тесно связаны с управлением транзакциями.
6. Сервисы контроля доступа к данным. СУБД должна иметь механизм, гарантирующий возможность только санкционированного доступа к базе данных. Иногда требуется скрыть некоторые хранимые в базе данных сведения от других пользователей. Кроме того, базу данных следует защитить от любого несанкционированного доступа. Термин безопасность относится к защите базы данных от преднамеренного или случайного несанкционированного доступа.
7. Поддержка обмена данными. СУБД должна обладать способностью к интеграции с коммуникационным программным обеспечением. Большинство пользователей осуществляют доступ к базе данных с помощью терминалов. Иногда эти терминалы подсоединены непосредственно к компьютеру с СУБД. В других случаях терминалы могут находиться на значительном удалении и обмениваться данными с компьютером, на котором располагается СУБД, через сеть. В любом случае СУБД получает запросы в виде сообщений обмена данными (communications messages) и аналогичным образом отвечает на них. Такая передача данных управляется менеджером обмена данными. Хотя этот менеджер не является частью собственно СУБД, тем не менее, чтобы быть коммерчески жизнеспособной, любая СУБД должна обладать способностью интеграции с разнообразными существующими менеджерами обмена данными. Даже СУБД для персональных компьютеров должны поддерживать работу в локальной сети, чтобы вместо нескольких баз данных для каждого пользователя можно было установить одну централизованную базу данных и использовать ее как общий ресурс для всех пользователей. При этом предполагается, что не база данных должна быть распределена в сети, а удаленные пользователи должны иметь возможность доступа к централизованной базе данных. Такая топология называется распределенной обработкой.
8. Службы поддержки целостности данных. СУБД должна обладать инструментами контроля за тем, чтобы данные и их изменения соответствовали заданным правилам. Целостность базы данных означает корректность и непротиворечивость хранимых данных. Она может рассматриваться как еще один тип защиты базы данных, но в более широком смысле целостность связана с качеством самих данных. Целостность обычно выражается в виде ограничений или правил сохранения непротиворечивости данных (например, сотрудник не имеет права работать больше, чем на полторы ставки в данной организации).
9. Службы поддержки независимости от данных. СУБД должна обладать инструментами поддержки независимости программ от фактической структуры базы данных. Обычно она достигается за счет реализации механизма поддержки представлений или подсхем. Физическая независимость от данных достигается достаточно просто, что нельзя сказать о логической независимости от данных. Как правило, система легко адаптируется к добавлению нового объекта, атрибута или связи, но не к их удалению. В некоторых системах вообще запрещается вносить любые изменения в уже существующие компоненты логической схемы.
10. Вспомогательные службы. СУБД должна предоставлять некоторый набор различных вспомогательных служб. Вспомогательные утилиты обычно предназначены для оказания помощи администратор БД (АБД) в эффективном администрировании базы данных. Приведем примеры таких утилит:
- утилиты импортирования, предназначенные для загрузки данных из плоских файлов или других СУБД, а также утилиты экспортирования, которые служат для выгрузки базы данных в плоские файлы или другие СУБД;
- средства мониторинга, предназначенные для отслеживания характеристик функционирования и использования базы данных;
- программы статистического анализа, позволяющие оценить производительность или степень использования базы данных;
- инструменты реорганизации индексов, предназначенные для перестройки индексов и обработки случаев их переполнения;
- инструменты сборки мусора и перераспределения памяти для физического устранения удаленных записей с запоминающих устройств, объединения освобожденного пространства и перераспределения памяти в случае необходимости.
В качестве основных классификационных признаков СУБД можно использовать следующие: вид программы, характер использования, модель данных.
К СУБД относятся следующие основные виды программ.
- Полнофункциональные СУБД (ПФСУБД). К ПФСУБД относятся, например, такие пакеты как: Clarion Database Developer, DataBase, Dataplex, dBase IV, Microsoft Access, Microsoft FoxPro и Paradox R:BASE. ПФСУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать запросы, разрабатывать отчеты, выводить их на печать и т. п. Для создания запросов и отчетов не обязательно программирование, а удобно пользоваться языком QBE (Query By Example — формулировки запросов по образцу). Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные СУБД имеют факультативные модули.
- Серверы БД. Предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД реализуют функции управления базами данных, запрашиваемые другими (клиентскими) программами обычно с помощью операторов SQL. Примерами серверов БД являются следующие программы: NetWare SQL (Novell), MS SQL Server (Microsoft), InterBase (Borland), SQLBase Server (Gupta), Intelligent Database (Ingress).
- Клиенты БД. В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты и т. д. При этом элементы пары «клиент — сервер» могут принадлежать одному или разным производителям программного обеспечения. Примером такого соединения является случай, когда одна из полнофункциональных СУБД играет роль сервера, а вторая СУБД (другого производителя) — роль клиента. Так, для сервера БД SQL Server (Microsoft) в роли клиентских (фронтальных) программ могут выступать многие СУБД, такие как: dBASE IV, Blyth Software, Paradox, DataBase, Focus, 1-2-3, MDBS III, Revelation и др.
- Средства разработки программ работы с БД. Используются для создания пользовательских приложений по работе с БД, серверов БД и их отдельных компонентов, клиентских программ. К средствам разработки программ для работы с БД относятся системы программирования (Clipper, Delphi, Power Builder (Borland), Visual Basic (Microsoft) и пр.); библиотеки программ для различных языков программирования; пакеты автоматизации разработок (SILVERRUN (Computer Advisers Inc.), S-Designor (SDP и Powersoft), ERwin (LogicWorks), Rational Rose и пр.).
- Дополнительные средства. Используются для управления данными и организации обслуживания БД (например, мониторы транзакций).
Классификация СУБД по характеру использования.
- Персональные СУБД обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД относятся Visual FoxPro, Paradox, Clipper, dBase, Access и др.
- Многопользовательские СУБД включают в себя сервер БД и клиентскую часть и, как правило, могут работать в неоднородной вычислительной среде (с разными типами ЭВМ и операционными системами). К многопользовательским СУБД относятся, например, СУБД Oracle и Informix.
Классификация СУБД по используемой модели данных: иерархические, сетевые, реляционные, постреляционные, многомерные, объектно-ориентированные. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.
Реляционная и постреляционная модели данных. Сравнительная характеристика. Реляционная модель
Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation). Отношение представляет собой множество элементов, называемых кортежами. Подробно теоретическая основа реляционной модели данных рассматривается в следующем разделе. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица. Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения. С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно: деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и образование. Поскольку в рамках одной таблицы не удается описать более сложные логические структуры данных из предметной области, применяют связывание таблиц. Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов. Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми. Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей. Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие: dBaseIII Plus и dBase IY (фирма Ashton-Tate), DB2 (IBM), R:BASE (Microrim)… К отечественным СУБД реляционного типа относятся системы: ПАЛЬМА (ИК АН УССР), а также система HyTech (МИФИ). Заметим, что последние версии реляционных СУБД имеют некоторые свойства объектно-ориентированных систем. Такие СУБД часто называют объектно-реляционными. Примером такой системы можно считать продукты Oracle 8.x. Системы предыдущих версий вплоть до Oracle 7.x считаются "чисто" реляционными.