ЗНАЕТЕ ЛИ ВЫ?

По специальности 230105 – «Программное обеспечение вычислительной техники и автоматизированных систем»



По специальности 230105 – «Программное обеспечение вычислительной техники и автоматизированных систем»

 

(для студентов очной и заочной формы обучения)

 


Содержание

1. Организационно-методическая часть (Программа дисциплины) 2

1.1. Цели и задачи дисциплины.. 2

1.2. Требования к уровню освоения содержания дисциплины.. 3

1.3. Объем дисциплины и виды учебной работы (в часах) 3

1.4. Содержание дисциплины.. 3

1.5. Перечень практических занятий. 6

1.6. График выполнения самостоятельных работ студентами. 7

1.7. Рекомендуемая литература. 8

2. Конспект лекций (семестр 5) 9

2.1. Введение в базы данных. 9

2.2. Классификация моделей данных. 12

2.3. Язык SQL.. 17

2.4. Проектирование баз данных. 27

2.5.Физические модели баз данных. 33

2.6. Распределённая обработка данных. 35

2.7. Обеспечение безопасности в БД.. 42

2.8. Современные направления исследований и разработок. 44

3. Конспект лекций (семестр 6) 48

3.1. Представления. 48

3.2. Компоненты языка Transact-SQL.. 50

3.3. Курсоры.. 55

3.4. Хранимые процедуры.. 58

3.5. Триггеры.. 60

4. Задания для проведения семинарских занятий. 62

5. Контрольные и самостоятельные работы.. 76

6. Вопросы к экзамену (семестр 5) 88

7. Вопросы к зачёту(семестр 6) 91

8. Форма итогового контроля. 91

1. Организационно-методическая часть (Программа дисциплины)

1.1. Цели и задачи дисциплины

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

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

Цели дисциплины заключаются в следующем:

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

· подробное изучение конкретной СУБД реляционного типа, ее возможностей и особенностей,

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

· приобретение навыков реализации прикладного ПО с помощью выбранной СУБД.

1.2. Требования к уровню освоения содержания дисциплины

В результате изучения дисциплины студенты должны:

· знать основные понятия, связанные с архитектурой баз данных, с реляционной моделью данных; методы, используемые для проектирования БД: метод “сущность—связь” и метод нормализации; физические модели данных; основные принципы распределённой обработки данных, основные подходы к обеспечению безопасности БД; а также основные возможности СУБД реляционного типа;

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

· знать и практически уметь на языке манипулирования данными SQL формулировать запросы к БД,

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

1.3. Объем дисциплины и виды учебной работы (в часах)

Вид занятий Всего часов Семестр
Общая трудоемкость дисциплины
Аудиторные занятия
Лекции (л) -
Практические занятия (пз)
Лабораторные работы (лр) - - -
Самостоятельная работы
Курсовой проект (работа) - - -
Реферат - - -
Вид итогового контроля (зачет, экзамен)   экзамен зачет

1.4. Содержание дисциплины

1.4.1. Разделы дисциплин и виды занятий

 

№ п/п   Наименование темы   Лекции   ПЗ или С   ЛР  
5 с е м е с т р
1.   Введение.   2 часа   2 часа    
2.   Основные понятия. Модели данных.   4 часа        
3. Язык SQL. Формирование запросов к БД. 8 часов 24 часа  
4. Основы проектирования баз данных. 8 часов 8 часов  
5. Физические модели баз данных. 4 часа    
6. Распределённая обработка данных. 3 часа    
7. Обеспечение безопасности в БД. 2 часа    
8. Современные направления развития БД и СУБД. 3 часа    
  ИТОГО: 34 часа 34 часа  
6 с е м е с т р
9. Введение в представления.   2 часа  
10.   Программирование в СУБД.   6 часа  
11. Курсоры.   8 часов  
12. Хранимые процедуры.   8 часов  
13. Триггеры и пользовательские функции.   8 часов  
14. Методы и модели анализа данных.   2 часа  
  ИТОГО:   34 часа  

1.4.2. Содержание разделов дисциплины

 

СЕМЕСТР 5

Тема 1. Введение.

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

 

Тема 2. Основные понятия. Модели данных.

База данных, СУБД, банк данных. Предметная область. Объекты и атрибуты, связи между объектами и атрибутами объектов. Уровни представления БД. Архитектура БД. Физическая и логическая независимость. Понятие схемы и подсхемы. Типы моделей данных. Иерархическая, сетевая, реляционная модели данных. Основные определения: отношения, домены, кортежи, атрибуты. Схема отношения, его степень и мощность. Реляционная БД. Первичный ключ. Свойства отношений реляционной БД. Операции над отношениями. Реляционная алгебра.

 

Тема 3. Язык SQL. Формирование запросов к БД.

Структура SQL. Типы данных. Создание, изменение и удаление таблиц. Ограничения значений данных. Поддержка ссылочной целостности. Ввод, изменение и удаление данных. Структура оператора SELECT. Запросы к нескольким таблицам. Агрегатные функции и вложенные запросы. Использование операторов подзапросов. Объединение запросов.

 

Тема 4. Основы проектирования баз данных.

Цели проектирования. Этапы проектирование БД. Системный анализ предметной области. Инфологическое проектирование. Даталогическое проектирование. ER – моделирование (модель “сущность - связь”). Сущности, связи и их свойства. Нотации Чена и “птичья лапка”. Нормализация таблиц БД. Декомпозиция отношений. Функциональные зависимости. Транзитивные зависимости. Многозначные зависимости. Нормальные формы 1НФ - 5НФ, нормальная форма Бойса-Кодда.

 

СЕМЕСТР 6

Тема 11. Курсоры.

Понятие о курсорах. Характеристики курсоров. Типы курсоров (статические, ключевые, динамические, курсоры быстрого доступа). Создание, открытие, закрытие курсоров. Оператор FETCH. Мониторинг курсоров.

 

Конспект лекций (семестр 5)

Введение в базы данных

Основные понятия баз данных

Информация, хранящаяся в базах данных, является отражением объектов реального мира. В традиционной терминологии объекты реального мира, сведения о которых хранятся в базе данных, называются сущностями — entities, а их актуальные признаки — атрибутами (attributes).

 

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

Важнейшая задача компьютерных систем — хранение и обработка данных. Для ее решения были предприняты усилия, которые привели к появлению в конце 60-х годов специализированного программного обеспечения — систем управления базами данных (СУБД, database management systems).

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

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

Сервер БД является неотъемлемым компонентом модели взаимодействия «клиент-сервер», которая стала фактическим стандартом архитектуры современных СУБД и одним из этапов их развития от систем с централизованной архитектурой и систем с файловым сервером.

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

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

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

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

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

· Позволяет вставлять, обновлять и извлекать информацию из базы данных, что осуществляется с помощью языка управления данными (DML - Data Manipulation Language). Наличие централизованного хранилища всех данных и их описаний позволяет использовать язык DML как общий инструмент организации запросов, который иногда называют языком запросов.

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

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

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

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

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

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

 

Этапы развития СУБД

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

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

С созданием реляционной модели данных был начат новый этап в эволюции СУБД. Простота и гибкость модели привлекли к ней внимание разработчиков и снискали ей множество сторонников. Реляционная модель данных стала доминирующей. Условно эту группу систем можно назвать "вторым поколением СУБД". Его характеризовали две основные особенности — реляционная модель данных и язык запросов SQL (Structured Query Language).

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

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

Требования к системам управления базами данных

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

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

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

Архитектура баз данных

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American Standards Institute) трехуровневая система организации БД, изображенная на рис. 1:

Архитектура баз данных

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

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

· все сущности, их атрибуты и связи;

· накладываемые на данные ограничения;

· семантическая информация о данных;

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

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

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

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

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

Иерархическая модель

В основе иерархическая древовидная структура данных.

Основные понятия: БД, сегмент (аналог записи), поле.

Есть тип сегмента и экземпляр сегмента.

(Ф.И.О., дата рождения) (характеристика типа сегмента, например, Иванов, 12.03)

Существуют первичные ключи.

Сегменты объединяются в ориентированную древовидный сетевой граф.

Существует только 1 корневой узел (сегмент).

 

А B C А – логически исходный сегмент B, С – логически подчиненные (имеет только 1 логически исходный)

Для работы с иерархическими моделями существует 2 языка: ЯОД (язык описания данных), ЯМД (язык манипулирования данных)

DBD Name = Кадры,

Access =< способ доступа>,

ЯМД:

1. оператор поиска

2. оператор поиска с возможностью модификации (изменения)

3. операторы модификации:

- удалить

- обновить

- добавить

 

Сетевая модель

Объекты: элемент данных, агрегат данных, запись и набор данных

Элемент данных – единица данных в поле

Агрегат данных:

- типа вектор, (Адрес: город, улица, дом, кв)

- типа повторяющаяся группа (з\п: месяц, сумма)

Запись – совокупность агрегатов или элементов данных, моделирующих некий класс объектов (сегмент в иерарх. модели)

Набор данных – двухуровневый граф связанный отношением один ко многим 2 типа записей. (1 тип –единичная, 2 тип – множественная)

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

Преподаватель группа № пары Ауд. Дисц. День недели

Иванов 4306 1 13 БД пн.

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

Описание БД области размещения

Описание записи: описываются элементы и агрегаты

Описание наборов

ЯОД и ЯМД:

1. навигационные операции

2. операции модификации

 

Язык SQL

Первый международный стандарт языка SQL был принят в 1989 г. (SQL/89 или SQL1), в 1992 г. был принят стандарт языка SQL (SQL/92 или SQL2). В 1999 г. появился стандарт SQL3. В SQL3 введены новые типы данных, при этом предоставляется возможность задания сложных структурированных типов данных, которые в большей степени соответствуют объектной ориентации. Появились стандарты на события и триггеры, которые раньше не затрагивались в стандартах.

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

Каждый столбец в любой таблице хранит данные определенных типов. Различают базовые типы данных:

· строки символов фиксированной длины;

· целые и вещественные числа;

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

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

Структура языка SQL

Язык SQL делится на подмножества.

1) Язык определения данных (DDL – Data Definition Language) предоставляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных.

Операторы: CREATE, ALTER, DROP.

2) Язык манипулирования данными (DML – Data Manipulation Language) позволяет вставлять, обновлять и извлекать информацию из базы данных.

Операторы: SELECT, INSERT, DELETE, UPDATE.

3) Язык управления данными (DCL – Data Control Language) состоит из управляющих операторов.

Операторы – GRANT, REVOKE.

4) Язык управления транзакциями (TCL – Transaction Control Language) состоит из операторов, предназначенных для управления ходом выполнения транзакций.

Операторы: COMMIT, ROLLBACK, SAVEPOINT.

 

Подмножество языка DML

Создание таблицы

Оператор CREATE служит для создания любого типа объектов, из которых состоит база данных, в том числе таблиц[1].

Синтаксис команды создания таблицы:

CREATE TABLE имя_таблицы(

поле1 тип1 [ограничения],

[поле2 тип2 [ограничения], …]);

Возможные ограничения в таблицах:

· NOT NULL – значение атрибута должно быть определено (опция NOT NULL);

· UNIQUE – значения атрибутов являются уникальными (уникальный ключ);

· PRIMARY KEY – атрибут является первичным ключом (первичный ключ);

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

· DEFAULT – присвоение значений «по умолчанию» для атрибутов.

Например:

CREATE TABLE Dealers1(

D_id NUMBER,

Name VARCHAR2(30),

Procent NUMBER(4,2),

Comments VARCHAR2(50) DEFAULT ‘no comments’);

Оператор ALTER

Оператор ALTER служит для изменения структуры любых объектов, из которых состоит база данных. В зависимости от типа объекта, изменяются и параметры команды ALTER. Далее рассмотрены примеры применения команды ALTER для изменения структуры объектов TABLE.

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

ALTER TABLE имя_таблицы ADD поле тип [ограничения];

Например, для добавления к таблице Dealers целого поля Age можно выполнить следующую команду:

ALTER TABLE Dealers ADD Age NUMBER(2);

 

Для удаления атрибута таблицы применяется следующий синтаксис:

ALTER TABLE имя_таблицы DROP COLUMN поле;

Например, для удаления поля Age из таблицы Dealers можно выполнить следующую команду:

ALTER TABLE Dealers DROP COLUMN Age;

Для изменения типа данных атрибута, размера типа данных или наличия опции NOT NULL используется следующие синтаксис:

ALTER TABLE имя_таблицы MODIFY поле тип [ограничения];

Оператор DROP

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

DROP тип объекта имя объекта;

Например, для удаления таблицы Dealers из базы данных необходимо выполнить следующую команду:

DROP TABLE Dealers;

 

Подмножество языка DML

Оператор выбора SELECT

Синтаксис оператора SELECT имеет следующий вид:

SELECT [ALL | DISTINCT] <список полей> | *

FROM <список таблиц>

[WHERE <условие фильтрации строк>]

[GROUP BY <условия группировки строк>]

[HAVING <условие фильтрации групп>]

[ORDER BY <условие сортировки результата запроса>]

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

Вложенные подзапросы

Виды вложенных подзапросов

Вложенный подзапрос – это оператор SELECT, заключенный в круглые скобки и вложенный в команду языка DML, и использующийся в качестве источника данных для параметров SELECT, FROM, WHERE и HAVING. Каждый подзапрос в свою очередь может содержать в себе подзапрос и т.д. В каждой СУБД существуют ограничения на количество вложенных подзапросов, но обычно этих ограничений хватает, чтобы реализовать задачи любой известной сложности.

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

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

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

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

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

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

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

Проектирование баз данных

Цели проектирования

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

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

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

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

Таким образом, при проектировании базы данных решаются две основные проблемы:

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

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

§

Этапы проектирования

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

Этап 4. Перенос глобальной логической модели данных в среду СУБД. Этап включает в себя следующие стадии:

проектирование основных таблиц в среде СУБД;

реализация бизнес-правил предприятия в среде СУБД.

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

1. анализ транзакций;

2. выбор файловой структуры;

3. определение вторичных индексов;

4. анализ необходимости введения контролируемой избыточности данных;

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

Этап 6. Разработка механизмов защиты.

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

2. определение прав доступа.

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

 

Характеристика связей

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

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

Между двумя сущностям, например, А и В возможны три типа связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Третий тип – связь МНОГИЕ-КО-МНОГИМ (М:М): экземпляр одной сущности связан с несколькими экземплярами другой сущности и наоборот, любой экземпляр второй сущности связан с несколькими экземплярами первой сущности.

 

Ограничения целостности

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность (корректность, правдоподобность, однозначность, непротиворечивость) данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах. Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7), то есть создать домен ­– указать перечень всевозможных значений того или иного атрибута.

Для того чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).

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

Выделяют четыре вида целостности:

  • целостность по сущностям (декларативная целостность);
  • целостность по ссылкам (ссылочная целостность – referential integrity);
  • целостность, определяемая пользователем (семантическая целостность);
  • физическая целостность (целостность файлов операционной системы).

 

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

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

· тип данных;

· размер типа данных;

· опция NOT NULL;

· домен;

· первичный ключ;

· уникальный ключ.

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

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

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

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

· Каскадирование: операция удаления «каскадируется» с тем, чтобы удалить также поставки этого поставщика.

· Ограничение: удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.

· Установка: для всех поставок удаляемого поставщика внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

В качестве примера рассматривается пример использования ER-проектирования (модель «птичья лапка») при проектировании системы работы колледжа.


Полная ER-диаграмма Tiny College

 

 

Инвертированные списки

Осуществляется доступ по первичным ключам. Инвертированный список – это двухуровневая индексная структура. На первом уровне упорядо





Последнее изменение этой страницы: 2017-01-25; Нарушение авторского права страницы

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.238.107.166 (0.046 с.)