Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ekzamenatsionnye_voprosy_po_TRZBD.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
346.67 Кб
Скачать
    1. Разработка и управление бд средствами языка sql.

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

· создание баз данных и таблиц с полным описанием их струк­туры;

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

· выполнение простых и сложных запросов.

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

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

Язык SQL отвечает практически всем этим требованиям.

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

· язык DDL (Data Definition Language), предназначенный для определения структур базы данных и управления доступом к дан­ным;

· Язык DML(DataMunipulation Language), предназначенный для выборки и обновления данных.

Язык SQL — это специальный и пока единственный стандарт­ный язык разработки и управления (манипулирования) реляци­онными базами данных, составляющий основу всех современных СУБД: Fox Pro, Microsoft Access, Oracle, SQL-Server и др.

Стандартом ISO 1900:2000 в SQL установлены следующие тер­мины, определяющие структуру базы данных: таблица, столбец и строка.

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

· каждая конструкция в операторе должна начинаться с новой строки;

· начало каждой конструкции оператора должно обозначаться одним и тем же отступом;

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

· для записи зарезервированных слов должны использоваться прописные буквы;

· для записи слов, определяемых пользователем, должны ис­пользоваться строчные буквы;

· вертикальная черта (|) указывает на необходимость выбора одного из нескольких приведенных значений, например а | b| с;

· фигурные скобки определяют обязательный элемент, напри­мер {а};

· квадратные скобки определяют необязательный элемент, на­пример [а];

· многоточие (...) используется для указания многократного (необязательного) повторения выполнения группы операторов.

Например, запись {а | b} [, с ...] означает, что после а или b могут несколько раз повторяться символы с, разделенные запя­тыми.

    1. Элементы и конструкции языка sql. Управление данными с помощью языка sql.

Язык SQL (Structured Query Language) относится к языку структурированных запросов. Он также является универсальным компьютерным языком используемым для создания, изменения и управления данными в реляционных базах данных. Не смотря на имеющиеся заблуждения язык SQL является информационно-логическим, а не языком программирования.

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

Администрирование баз данных. В этом случае SQL используется администратором базы данных для установления структуры базы данных и управления доступом к данным.

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

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

    1. Применение операторов SQL для определения и управления данными.

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

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

Базовый элемент концептуальной модели: бизнес-сущность.

Примеры бизнес-сущностей:

Клиент (как вариант, клиент-ФЛ, клиент-ЮЛ),

Продукт (как вариант, товар, услуга),

Сделка (как вариант, заказ).

Концептуальная модель наиболее сильно отражается в документах класса ГЛОССАРИЙ. Схематически (графически) наиболее удобным способом отображение концептуальной модели является диаграмма классов. Однако строгие нотации моделирования для концептуального уровня скорее всего окажутся обременением и лучше использовать их на логическом уровне для проверки результирующей модели. Связи между бизнес-сущностями полезно «окрашивать» действиями из предметной области, например, клиент заключает сделку, заказ состоит из товаров. Наилучшая нотация для концептуального уровня – Archimate (business layer). В данной нотации бизнес-сущности могут быть привязаны к ряду элементов бизнес-слоя, что улучшает их окрашивание или лучше структурирует (делает более наглядной) моделируемую предметную область.

Логическая модель является уточнением и детализацией концептуальной модели. Но это лишь с одной стороны. На построение логической модели также влияет:

Тип планируемой СУБД, которая будет воплощать модель

Класс проектируемой системы: операционная (транзакционная) или аналитическая (BI)

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

Физический уровень – это уровень таблиц для реляционных моделей данных.

Базовый элемент физической модели: таблица.

Примеры таблиц:

Клиент -► table_1

Продукт -► table_2

Сделка -► table_3

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

Фокус моделирования:

Выделение отдельных таблиц (в том числе как результат нормализации данных).

Выделение справочников.

Определение ключей.

Разделение атрибутов на простые атрибуты и перечисления (будущие справочники)

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

    1. Обеспечение непротиворечивости и целостности данных.

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

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

1. Каждая строка таблицы должна отличаться от остальных ее строк значением хотя бы одного столбца.

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

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

Пример. В столбце Название отдела таблицы СОТРУДНИК хранятся сведения о принадлежности сотрудников к отделу, т. е. этот столбец является внешним ключом для ссылки на таблицу ОТДЕЛ для обеспечения ограничения целостности данных по ссылкам каждое название отдела из таблицы СОТРУДНИК должно принадлежать конкретному столбцу из таблицы ОТДЕЛ.

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

    1. Классификация инструментальных средств проектирования структур БД.

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

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

Классификация CASE-средств включает следующие основные типы:

· средства анализа(Upper CASE), предназначенные для построения и анализа моделей предметной области: Design/IDEF (Meta Software), BPwin (Logic Works);

· средства анализа и проектирования(Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций: Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся: ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

· средства разработки приложений. К ним относятся средства 4GL: Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др., а также генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично в Silverrun;

· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne).

    1. Обзор средств автоматизированного проектирования структур БД (Allfusion, VisioEnterprise и т.п.).

    1. Приемы графического проектирования структуры БД

    2. Технология проектирования серверной части приложения БД

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

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

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

1)Создание локальной концептуальной модели данных.

2)Определение типов сущностей.

3)Определение атрибутов.

4)Определение типов связей.

5)Проверка модели на избыточность.

6)Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

7)Обсуждение локальных концептуальных моделей данных с конечными пользователями.

8)Создание локальной концептуальной модели данных. Целью дан­ного этапа является определение предметной области и состава пользователей разрабатываемой базы данных.

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

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

1)Создание и проверка локальной логической модели данных на основе представления предметной области каждого из типов пользователей

2)Устранение особенностей локальной логической модели, несовместимых с реляционной моделью (необязательный этап).

3)Определение набора отношений исходя из структуры локаль­ ной логической модели данных.

4)Проверка отношений с помощью правил нормализации таб­ лиц.

5)Проверка соответствия отношений требованиям пользова­ тельских транзакций.

6)Определение требований поддержки целостности данных.

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

8)Создание и проверка глобальной логической модели данных.

9)Слияние локальных логических моделей данных в единую глобальную модель данных.

10)Проверка глобальной логической модели данных.

11)Проверка возможностей расширения модели в будущем

12)Обсуждение глобальной логической модели данных с пользователями.

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

Физическое проектирование базы данных (для реляционной модели) включает в себя следующие этапы.

1)Перенос глобальной логической модели данных в среду целевой СУБД.

2)Проектирование базовых отношений в среде целевой СУБД.

3)Проектирование отношений, содержащих производные данные.

4)Реализация ограничений предметной области.

5)Проектирование физического представления базы данных.

6)Анализ транзакций.

7)Выбор файловой структуры.

8)Определение индексов.

9)Определение требований к дисковой памяти.

10)Разработка пользовательских представлений.

11)Разработка механизмов защиты.

12)Анализ необходимости введения контролируемой избыточ­ности.

13)Организация мониторинга и настройка функционирования операционной системы.

    1. Создание хранимых процедур и триггеров в БД

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

Создание пользовательских представлений

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

Для создания нового представления требуется в диалоговом окне «Другие представления» (Вид-Представления ресурсов-Другие представления) нажать кнопку «Создать», как показано на рисунке 34.

Для создания нового комбинированного представления установите переключатель в положение «Комбинированное представление». Затем в диалоговом окне «Определение представления» выберите основное отображаемое представление и представление для области сведений.