Организация и ведение баз данных средствами СУБД MS ACCESS
Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, иметь всю необходимую информацию для удовлетворения предполагаемых запросов пользователя и определять потребности в обработке данных.
На основе такого описания на этапе проектирования базы данных определяется состав и структура данных, которые должны находиться в базе данных и обеспечивать выполнение необходимых запросов и решение задач пользователя.
Процесс проектирования и создания реляционной базы данных состоит из следующих этапов:
1) создание информационно – логической модели предметной области, т.е. выделение информационных объектов и определение связей между ними;
2) построение логической структуры реляционной базы данных, где каждый объект инфологической модели отображается реляционной таблицей, а связи между таблицами соответствуют выявленным информационным связям между объектами;
3) конструирование таблиц, соответствующих информационным объектам построенной модели данных;
4) создание схемы данных, в которой фиксируются существующие логические связи между таблицами;
5) ввод данных, содержащихся в документах предметной области.
Особый внимание следует уделить первым двум этапам, поскольку без их тщательной проработки невозможно создание БД, полностью удовлетворяющей потребностям пользователя.
Построение инфологической модели данных. Инфологическая модель (ИЛМ) отображает данные предметной области в виде совокупности информационных объектов и связей между ними.
Информационный объект – это информационное описание некоторого реального объекта, процесса или события. Информационный объект образуется совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики некоторой сущности предметной области. Например, объект ТОВАР характеризуется такими реквизитами как наименование, единица измерения, изготовитель, сорт, цена и др.
Каждому информационному объекту присваивают уникальное имя, Например, при описании предметной области поставка товаров будут выделены такие объекты как ТОВАР, ПОСТАВЩИК.
Информационный объект имеет множество реализаций – экземпляров (записей). Например каждый экземпляр объекта ТОВАР представляет конкретный вид продукции. Экземпляр образуется совокупностью конкретных значений реквизитов и должен однозначно идентифицироваться значением ключа информационного объекта. Ключ может состоять из одного (простой ) или нескольких ключевых реквизитов (составной ).
При проектировании реляционной базы данных необходимо решить вопрос о наиболее эффективной структуре данных. При этом преследуются следующие цели:
Обеспечить быстрый доступ к данным в таблицах.
Исключить ненужное повторение данных, которое может являться причиной ошибок при вводе и нерационального использования дискового пространства компьютера.
Обеспечить целостность данных таким образом, чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ним объектов.
Следующим шагом на этапе проектирования ИЛМ, после выявления информационных объектов, является определение отношений между ними.
Отношение – это связь между двумя таблицами, которая показывает, как относятся друг к другу данные в этих таблицах. При создании отношения указываются одинаковые поля в двух разных таблицах. Например, можно создать отношения между таблицами ТОВАР и ПОСТАВЩИК, используя в качестве связующего поля идентификатор товара.
ACCESS поддерживает следующие типы отношений между таблицами:
Одно – однозначные (1:1),
Одно – многозначные (1:М),
Много – многозначные (N:М).
Одно – однозначные связи (1:1) имеют место, когда каждому экземпляру одного объекта (А) соответствует только один экземпляр другого объекта (В) и, наоборот, каждому экземпляру объекта (В) соответствует только один экземпляр объекта (А).
Одно – многозначные связи (1:М) – это такие связи, когда каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров объекта (В), а каждому экземпляру объекта (В) может соответствовать только один экземпляр объекта (А). В такой связи объект А является главным объектом, а объект В – подчиненным.
Много – многозначные (N:М) – имеют место в том случае, если каждому экземпляра объекта А может соответствовать несколько экземпляров объекта В и, наоборот, каждому экземпляру объекта В может соответствовать несколько экземпляров объекта А.Для реализации таких связей используется объект –«связка», который должен иметь идентификатор, образованный из идентификаторов объектов А и В.
В ИЛМ объекты размещены по уровням. На нулевом уровне размещаются объекты, не подчиненные другим объектам. Уровень остальных объектов определяется наиболее длинным путем к объекту от нулевого уровня. Такое размещение объектов дает представление об их иерархической подчиненности, делает модель более наглядной и облегчает понимание связей между объектами.
Построение логической модели базы данных. Логическая структура базы данных является адекватным отображением полученной инфологической модели. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура таблицы определяется реквизитным составом объекта, где каждый столбец соответствует одному реквизиту. Строки таблицы соответствуют экземплярам объекта и формируются при загрузке таблицы.
Связи между объектами модели данных реализуются одинаковыми реквизитами – ключами связи в соответствующих таблицах. При этом ключом связи всегда должен быть идентификатор главного объекта.
Основные понятия баз данных.
База данных – это совокупность структурированных и взаимосвязанных данных, организованная по определенным правилам, которые предусматривают общие принципы описания, хранения и обработки данных.
Существуют 4 основные модели данных – списки (плоские таблицы), реляционные базы данных, иерархические и сетевые структуры.
В течение многих лет преимущественно использовались плоские таблицы (плоские БД) типа списков в Excel. В настоящее время наибольшее распространение при разработке БД получили реляционные модели данных. Реляционная модель данных является совокупностью простейших двумерных таблиц – отношений (англ. relation), т.е. простейшая двумерная таблица определяется как отношение (множество однотипных записей объединенных одной темой).
От термина relation (отношение) происходит название реляционная модель данных. В реляционных БД используется несколько двумерных таблиц, в которых строки называются записями , а столбцы полями , между записями которых устанавливаются связи. Этот способ организации данных позволяет данные (записи) в одной таблице связывать с данными (записями) в других таблицах через уникальные идентификаторы (ключи) или ключевые поля.
Основные понятия реляционных БД: нормализация, связи и ключи
1. Принципы нормализации:
В каждой таблице БД не должно быть повторяющихся полей;
В каждой таблице должен быть уникальный идентификатор (первичный ключ);
Каждому значению первичного ключа должна соответствовать достаточная информация о типе сущности или об объекте таблицы (например, информация об успеваемости, о группе или студентах);
Изменение значений в полях таблицы не должно влиять на информацию в других полях (кроме изменений в полях ключа).
2. Виды логической связи.
Связь устанавливается между двумя общими полями (столбцами) двух таблиц. Существуют связи с отношением «один-к-одному», «один-ко-многим» и «многие-ко-многим».
один - к - одному – каждой записи из одной таблицы соответствует одна запись в другой таблице;
один - ко - многим – каждой записи из одной таблицы соответствует несколько записей другой таблице;
многие - к - одному – множеству записей из одной таблице соответствует одна запись в другой таблице;
многие - ко - многим – множеству записей из одной таблицы соответствует несколько записей в другой таблице.
Тип отношения в создаваемой связи зависит от способа определения связываемых полей:
Отношение «один-ко-многим» создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса.
Отношение «один-к-одному» создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.
Отношение «многие-ко-многим» фактически является двумя отношениями «один-ко-многим» с третьей таблицей, первичный ключ которой состоит из полей внешнего ключа двух других таблиц
3. Ключи . Ключ – это столбец (может быть несколько столбцов), добавляемый к таблице и позволяющий установить связь с записями в другой таблице. Существуют ключи двух типов: первичные и вторичные (внешние).
Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ используется для связывания таблицы с внешними ключами в других таблицах.
Внешний (вторичный) ключ - это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц.
Из двух логически связанных таблиц одну называют таблицей первичного ключа или главной таблицей, а другую таблицей вторичного (внешнего) ключа или подчиненной таблицей. СУБД позволяют сопоставить родственные записи из обеих таблиц и совместно вывести их в форме, отчете или запросе.
Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.
Поле счетчика (Тип данных «Счетчик»). Тип данных поля в базе данных, в котором для каждой добавляемой в таблицу записи в поле автоматически заносится уникальное числовое значение.
Простой ключ . Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null.
Составной ключ . В случаях, когда невозможно гарантировать уникальность значений каждого поля, существует возможность создать ключ, состоящий из нескольких полей. Чаще всего такая ситуация возникает для таблицы, используемой для связывания двух таблиц многие - ко - многим.
Необходимо еще раз отметить, что в поле первичного ключа должны быть только уникальные значения в каждой строке таблицы, т.е. совпадение не допускается , а в поле вторичного или внешнего ключа совпадение значений в строках таблицы допускается .
Если возникают затруднения с выбором подходящего типа первичного ключа, то в качестве ключа целесообразно выбрать поле счетчика.
Программы, которые предназначены для структурирования информации, размещения ее в таблицах и манипулирования данными называются системами управления базами данных (СУБД): MS SQL Server, Oracle, Informix, Sybase, DB2, MS Access и т. д.
Основы проектирования баз данных.
Создание БД начинается с проектирования.
Этапы проектирования БД:
· Исследование предметной области;
· Анализ данных (сущностей и их атрибутов);
· Определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.
В процессе проектирования определяется структура реляционной БД (состав таблиц, их структура и логические связи). Структура таблицы определяется составом столбцов, типом данных и размерами столбцов, ключами таблицы.
К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).
Сущность – любой конкретный или абстрактный объект в рассматриваемой предметной области. Сущности – это базовые типы информации, которые хранятся в БД (в реляционной БД каждой сущности назначается таблица). К сущностям могут относиться: студенты, клиенты, подразделения и т.д. Экземпляр сущности и тип сущности - это разные понятия. Понятие тип сущности относится к набору однородных личностей, предметов или событий, выступающих как целое (например, студент, клиент и т.д.). Экземпляр сущности относится, например, к конкретной личности в наборе. Типом сущности может быть студент, а экземпляром – Петров, Сидоров и т. д.
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Например, для сущности студент могут быть использованы следующие атрибуты: фамилия, имя, отчество, дата и место рождения, паспортные данные и т.д. В реляционной БД атрибуты хранятся в полях таблиц.
Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц).
Сущности – это данные, которые классифицируются по типу, а связи показывают, как эти типы данных соотносятся один с другим. Если описать некоторую предметную область в терминах сущности – связь, то получим модель сущность - связь для этой БД.
Рассмотрим предметную область: Деканат (Успеваемость студентов)
В БД «Деканат» должны храниться данные о студентах, группах студентов, об оценках студентов по различным дисциплинам, о преподавателях, о стипендиях и т.д. Ограничимся данными о студентах, группах студентов и об оценках студентов по различным дисциплинам. Определим сущности, атрибуты сущностей и основные требования к функциям БД с ограниченными данными.
Основными предметно-значимыми сущностями БД «Деканат» являются: Студенты, Группы студентов, Дисциплины, Успеваемость.
Основные предметно-значимые атрибуты сущностей:
· студенты – фамилия, имя, отчество, пол, дата и место рождения, группа студентов;
· группы студентов – название, курс, семестр;
· дисциплины – название, количество часов
· успеваемость – оценка, вид контроля.
Основные требования к функциям БД:
· выбрать успеваемость студента по дисциплинам с указанием общего количества часов и вида контроля;
· выбрать успеваемость студентов по группам и дисциплинам;
· выбрать дисциплины, изучаемые группой студентов на определенном курсе или определенном семестре.
Из анализа данных предметной области следует, что каждой сущности необходимо назначить простейшую двумерную таблицу (отношения). Далее необходимо установить логические связи между таблицами. Между таблицами Студенты и Успеваемость необходимо установить такую связь, чтобы каждой записи из таблицы Студенты соответствовало несколько записей в таблице Успеваемость, т.е. один – ко – многим, так как у каждого студента может быть несколько оценок.
Логическая связь между сущностями Группы – Студенты определена как один – ко – многим исходя из того, что в группе имеется много студентов, а каждый студент входит в состав одной группы. Логическая связь между сущностями Дисциплины – Успеваемость определена как один – ко – многим, потому что по каждой дисциплине может быть поставлено несколько оценок различным студентам.
à стрелка является условным обозначением связи: один – ко – многим.
В.В. Кириллов. Основы проектирования реляционных баз данных.
Учебное пособие
Санкт-Петербургский Гос.институт точной механики и оптики (техн.ун-т)
, Кафедра вычислительной техники
/database/dbguide/index.shtml
Глава 1. Что такое базы данных и СУБД 3
1.1. Данные и ЭВМ 3
1.2. Концепция баз данных 5
1.3. Архитектура СУБД 6
1.4. Модели данных 8
Глава 2. Инфологическая модель данных "Сущность-связь" 9
2.1. Основные понятия 9
2.2. Характеристика связей и язык моделирования 10
2.3. Классификация сущностей 14
Три класса сущностей 14
Стержневая сущность (стержень) 14
Ассоциативная сущность (ассоциация) 14
Характеристическая сущность (характеристика) 15
Обозначающая сущность или обозначение 15
Пример 15
2.4. О первичных и внешних ключах 18
2.5. Ограничения целостности 20
Понятие целостности данных 20
Виды целостности 20
2.6. О построении инфологической модели 21
Введение 21
Требования к БД со стороны администратора и прикладного программиста 21
Глава 3. Реляционный подход 22
3.1. Реляционная структура данных 22
Введение 22
Основные понятия 22
Понятие ключа 24
3.2. Реляционная база данных 24
Свойства Таблицы данных 25
3.3. Манипулирование реляционными данными 26
Глава 4. Введение в проектирование реляционных баз данных 27
4.1. Цели проектирования 27
Введение 27
Прикладные и предметные БД 27
Порядок проектирования БД 27
Цель проектирования БД 28
4.2. Универсальное отношение 29
Проект БД «Питание» 29
4.3. Почему проект БД может быть плохим? 30
4.4. О нормализации, функциональных и многозначных зависимостях 33
Понятие нормализации 33
Нормальные формы 33
Функциональная и многозначная зависимости 34
4.5. Нормальные формы 34
Первая нормальная форма (1НФ) 34
Вторая нормальная форма 2НФ 35
Третья нормальная форма 3НФ 36
Нормальная форма Бойса-Кодда НФБК 36
Понятие полной декомпозиции 4НФ и 5НФ 36
Четвертая нормальная форма 4НФ 37
4.6. Процедура нормализации 37
О понятии нормализации 37
Пример 4.1. Нормализация универсального отношения "Питание" 38
Шаг 1. Определение первичного ключа таблицы. 38
Шаг 2. Выявление полей, функционально зависящих от части состваного ключа. 38
Шаг 3. Формирование новых таблиц. 39
Шаг 4. Корректировка исходной таблицы. 39
Пример 4.2. Улучшение проекта 39
4.7. Процедура проектирования 39
Введение 39
Шаги процедуры проектирования даталогической модели 39
Векторы 42
Неопределенные значения. 42
Глава 5. Пример проектирования базы данных "Библиотека" 42
5.1. Назначение и предметная область 42
5.2. Построение инфологической модели 45
5.3. Проектирование базы данных 47
ЛИТЕРАТУРА 50
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ 51
Глава 1. Что такое базы данных и СУБД
1.1. Данные и ЭВМ
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными .
Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение "Стоимость авиабилета 128". Здесь "128" – данное, а "Стоимость авиабилета" – его семантика.
Нередко данные и интерпретация разделены. Например, "Расписание движения самолетов" может быть представлено в виде таблицы (рис. 1.1), в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить сведения из нижней части таблицы).
Интерпретация |
|||||||
Номер рейса | Дни недели | Пункт отправления | Время вылета | Пункт назначения | Время прибытия | Тип самолета | Стоимость билета |
Данные |
|||||||
Рис. 1.1. К разделению данных и их интерпретации
Применение ЭВМ для ведения * и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета или временем вылета). Почему же это произошло?
Существует по крайней мере две исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке – основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая "знала", например, что шестое вводимое значение связано с временем прибытия самолета, а четвертое – с временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.
Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими.
Нередки случаи, когда пользователи одной и той же ЭВМ создают и используют в своих программах разные наборы данных, содержащие сходную информацию. Иногда это связано с тем, что пользователь не знает (либо не захотел узнать), что в соседней комнате или за соседним столом сидит сотрудник, который уже давно ввел в ЭВМ нужные данные. Чаще потому, что при совместном использовании одних и тех же данных возникает масса проблем.
Разработчики прикладных программ (написанных, например, на Бейсике, Паскале или Си) размещают нужные им данные в файлах, организуя их наиболее удобным для себя образом. При этом одни и те же данные могут иметь в разных приложениях совершенно разную организацию (разную последовательность размещения в записи, разные форматы одних и тех же полей и т.п.). Обобществить такие данные чрезвычайно трудно: например, любое изменение структуры записи файла, производимое одним из разработчиков, приводит к необходимости изменения другими разработчиками тех программ, которые используют записи этого файла.
Для иллюстрации обратимся к примеру, приведенному в книге: У.Девис, Операционные системы, М., Мир, 1980:
"Несколько лет назад почтовое ведомство (из лучших побуждений) пришло к решению, что все адреса должны обязательно включать почтовый индекс. Во многих вычислительных центрах это, казалось бы, незначительное изменение привело к ужасным последствиям. Добавление к адресу нового поля, содержащего шесть символов, означало необходимость внесения изменений в каждую программу, использующую данные этой задачи в соответствии с изменившейся суммарной длиной полей. Тот факт, что какой-то программе для выполнения ее функций не требуется знания почтового индекса, во внимание не принимался: если в некоторой программе содержалось обращение к новой, более длинной записи, то в такую программу вносились изменения, обеспечивающие дополнительное место в памяти.
В условиях автоматизированного управления централизованной базой данных все такие изменения связаны с функциями управляющей программы базы данных. Программы, не использующие значения почтового индекса, не нуждаются в модификации - в них, как и прежде, в соответствии с запросами посылаются те же элементы данных. В таких случаях внесенное изменение неощутимо. Модифицировать необходимо только те программы, которые пользуются новым элементом данных.".
* Ведение (сопровождение, поддержка) данных – термин объединяющий действия по добавлению, удалению или изменению храни-мых данных.
1.2. Концепция баз данных
Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных " (СУБД).
Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных " (БД).
Пусть, например, требуется хранить расписание движения самолетов (рис. 1.1 ) и ряд других данных, связанных с организацией работы аэропорта (БД "Аэропорт"). Используя для этого одну из современных "русифицированных" СУБД, можно подготовить следующее описание расписания:
СОЗДАТЬ ТАБЛИЦУ Расписание
(Номер_рейса Целое
Дни_недели Текст (8)
Пункт_отправления Текст (24)
Время_вылета Время
Пункт_назначения Текст (24)
Время_прибытия Время
Тип_самолета Текст (8)
Стоимость_билета Валюта);
и ввести его вместе с данными в БД "Аэропорт".
Язык запросов СУБД позволяет обращаться за данными как из программ, так и с терминалов (рис. 1.2). Сформировав запрос
ВЫБРАТЬ Номер_рейса, Дни_недели, Время_вылета
ИЗ ТАБЛИЦЫ Расписание
И Пункт_назначения = "Киев"
И Время_вылета > 17;
получим расписание "Москва-Киев" на вечернее время, а по запросу
ВЫБРАТЬ КОЛИЧЕСТВО(Номер_рейса)
ИЗ ТАБЛИЦЫ Расписание
ГДЕ Пункт_отправления = "Москва"
И Пункт_назначения = "Минск";
получим количество рейсов "Москва-Минск".
Рис. 1.2. Связь программ и данных при использовании СУБД
Эти запросы не потеряют актуальности и при расширении таблицы:
ДОБАВИТЬ В ТАБЛИЦУ Расписание
Длительность_полета Целое;
как это было с программами обработки почтовых адресов при введении почтового индекса (см. п. 1.1 ).
Однако, за все надо расплачиваться: на обмен данными через СУБД требуется большее время, чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного приложения.
[Назад ] [Содержание ] [Вперед ]
1.3. Архитектура СУБД
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
физическом размещении в памяти данных и их описаний;
механизмах поиска запрашиваемых данных;
проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
поддержании баз данных в актуальном состоянии
и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?
Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 1.3).
Рис. 1.3. Уровни моделей данных
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели, показанные на рис. 1.3, являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных .
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных .
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
1.4. Модели данных
Как отмечалось в п. 1.3 , инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. [11 ]. Наиболее популярной из них оказалась модель "сущность-связь", которая будет рассмотрена в главе 2.
Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели [1 , 2 , 8 , 11 ].
Сначала стали использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.
Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база – это самый верный способ потерять данные".
Сложность практического использования иерархических и и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.
данных , рассматривается реляционная модель данных и проектирование реляционных баз данных ...
Базы данных (7)
Учебно-методический комплекс... Основы проектирования приложений баз данных : учеб. пособие / И.Ю. Баженова. - М.: ИНТУИТ. ру; БИНОМ. ЛЗ, 2006. - 324 с Базы данных : проектирование ... темами: Проектирование реляционных баз данных , Создание новой базы данных , Создание таблиц...
Государственное бюджетное профессиональное
образовательное учреждение
«Колледж автоматизации
и информац ионных технологий № 20»
РАБОЧАЯ ПРОГРАММА
учебной дисциплины_ ОП.07 Основы проектирования баз данных
код специальности/специальность 230401 ИНФОРМАЦИОННЫЕ СИСТЕМЫ (по отраслям)
уровень подготовки: __базовый ________
Москва
2015
ОДОБРЕНО
на заседании ПЦК «Библиотековедение», «ИС (по отраслям», «ОТЗИ»
Протокол № _от « » ______ 2015 г.
Председатель
_____________________________/Е.Е. Швец/
Программа учебной дисциплины разработана в соответствии с требованиями ФГОС по специальности 230401 Информационные системы и учебным планом
УТВЕРЖДАЮ
Руководитель учебного структурного подразделения «БТМ»
_____________________________/Т.И. Стеняева/
СОГЛАСОВАНО
Зав. учебно-методическим отделением
_____________________________/С.Е. Коваленко/
«_____» ________________________20__ г.
Разработчик (автор): ____ Федоткина М.В., преподаватель _______ _________________________________________________
Ф.И.О., должность, квалификационная категория
Рецензент:
Внешний: ______________________________________________
(Ф.И.О., место работы, должность, квалификационная категория (ученая степень, звание)
СОДЕРЖАНИЕ
стр.
ПАСПОРТ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ
СТРУКТУРА и содержание УЧЕБНОЙ ДИСЦИПЛИНЫ
условия реализации учебной дисциплины
Контроль и оценка результатов Освоения учебной дисциплины
1. паспорт Рабочей ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ
« ОП.07 Основы проектирования баз данных»
Область применения рабочей программы
Рабочая программа учебной дисциплины является частью основной профессиональной образовательной программы в соответствии с ФГОС по специальности СПО 230401 «Информационные системы (по отраслям) (базовый уровень) укрупненной группы специальностей 230000 Информатика и вычислительная техника.
Рабочая программа учебной дисциплины может быть использована в дополнительном профессиональном образовании в качестве факультативного курса для укрупненных групп специальностей 230000 Информатика и вычислительная техника, а также на курсах повышения квалификации для взрослого безработного населения.
Учебная дисциплина «Основы проектирования баз данных» является общепрофессиональной дисциплиной, формирующей базовый уровень знаний для освоения специальных дисциплин.
Преподавание дисциплины имеет практическую направленность и проводиться в тесной взаимосвязи с другими общепрофессиональными дисциплинами: «Информационные технологии», «Операционные системы и среды», «Архитектура ЭВМ и вычислительных систем».
1.2. Место учебной дисциплины в структуре основной профессиональной образовательной программы:
Учебная дисциплина относится к циклу профессиональных дисциплин к блоку общепрофессиональных дисциплин.
1.3. Цели и задачи учебной дисциплины - требования к результатам освоения учебной дисциплины:
Изучение дисциплины «Основы проектирования баз данных» направлено на формирование общих компетенций (ОК 1-10) и ПК 1.1, ПК 1.2, ПК 1.3, ПК 1.7,ПК 1.9. согласно ФГОС по специальности 230401 Информационные системы (по отраслям):
ОК 1. Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.
ОК 2. Организовывать собственную деятельность, выбирать типовые методы и способы выполнения профессиональных задач, оценивать их эффективность и качество.
ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.
ОК 4. Осуществлять поиск и использование информации, необходимой для эффективного выполнения профессиональных задач, профессионального и личностного развития.
ОК 5. Использовать информационно-коммуникационные технологии в профессиональной деятельности.
ОК 6. Работать в коллективе и команде, эффективно общаться с коллегами, руководством, потребителями.
ОК 7. Брать на себя ответственность за работу членов команды (подчиненных), результат выполнения заданий.
ОК 8. Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.
ОК 9. Ориентироваться в условиях частой смены технологий в профессиональной деятельности.
ОК 10. Исполнять воинскую обязанность, в том числе с применением полученных профессиональных знаний (для юношей).
ПК 1.1. Собирать данные для анализа использования и функционирования информационной системы, участвовать в составлении отчетной документации, принимать участие в разработке проектной документации на модификацию информационной системы.
ПК 1.2. Взаимодействовать со специалистами смежного профиля при разработке методов, средств и технологий применения объектов профессиональной деятельности
ПК 1.3. Производить модификацию отдельных модулей информационной системы в соответствии с рабочим заданием, документировать произведенные изменения.
ПК 1.7. Производить инсталляцию и настройку информационной системы в рамках своей компетенции, документировать результаты работ.
ПК 1.9. Выполнять регламенты по обновлению, техническому сопровождению и восстановлению данных информационной системы, работать с технической документацией.
В результате освоения дисциплины обучающийся должен
уметь :
Проектировать реляционную базу данных;
Использовать язык запросов для программного извлечения сведений из баз данных;
знать
:
Основы теории баз данных;
Модели данных; особенности реляционной модели и проектирование баз данных, изобразительные средства, используемые в ER-моделировании;
Основы реляционной алгебры; принципы проектирования баз данных,
Обеспечение непротиворечивости и целостности данных;
Средства проектирования структур баз данных; язык запросов SQL
1.4. Рекомендуемое количество часов на освоение примерной программы учебной дисциплины:
максимальной учебной нагрузки обучающегося 168 часов, в том числе:
обязательной аудиторной учебной нагрузки обучающегося 112 часа,
самостоятельной работы обучающегося 56 часов.
2. СТРУКТУРА И ПРИМЕРНОЕ СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ
2.1. Объем учебной дисциплины и виды учебной работы
Вид учебной работы
Объем часов
168
Обязательная аудиторная учебная нагрузка (всего)
112
в том числе:
лабораторные работы
48
практические занятия
10
контрольные работы
-
курсовая работа (проект) (если предусмотрено)
-
Самостоятельная работа обучающегося (всего)
56
в том числе:
самостоятельная работа над курсовой работой (проектом) не предусмотрено
-
Подготовка доклада на тему:
- «Информационные технологии будущего»;
- « Для каких объектов Acces можно создавать отчёты»;
- «Смысл новых перспективных направлений развития СУБД»;
Подготовка презентации на тему:
- «Способы задания таблиц в Access »;
- «Процесс создания запрос – выборка»;
Подготовка сообщения на тему:
- «Объекты программного средства (ПС) Access их назначение»;
- «Объект – Форма»;
- « Направление СУБД – Postgres »;
Реферат на тему:
- «Способы удаления атрибута в таблице»;
- «Опишите процесс установления связи между двумя таблицами в Acces »;
Выполнение индивидуального проекта тему :
- «Расписание занятий»;
9
Итоговая аттестация в форме экзамена
2.2. Тематический план и содержание учебной дисциплины оп.07 ОСНОВЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
Наименование
разделов и тем
Содержание учебного материала, лабораторные и практические работы, самостоятельная работа
обучающихся, курсовая работ (проект)
Объем часов
Уровень
освоения
1
2
3
4
Введение
Введение в теорию баз данных
Лабораторные работы не предусмотрено
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся не предусмотрено
Подготовить реферат на тему: «Связь БД с другими дисциплинами».
Раздел 1.
Базы данных. Основные понятия
12
Тема 1.1. Основные понятия и типы моделей данных
Содержание учебного материала
6
Дать понятия объекта, сущности, параметра, атрибута, модели данных. Рассмотреть состав информационной модели данных.
3
СУБД и ее место в системе программного обеспечения ЭВМ. Функции СУБД . Уровни представления данных.
Диалектический переход от одной модели к другой. Три типа логических моделей: иерархическая, сетевая и реляционная. Понятие логической и физической независимости данных.
Лабораторные работы не предусмотрено
-
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
1. Подготовка доклада на тему «Информационные технологии будущего»
3
Тема 1.2. Архитектура СУБД
Содержание учебного материала
2
Архитектуры баз данных (двух- и трёх-звенная структуры, клиент – сервер, файл - сервер).
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
2.Сообщение на тему: «Объекты программного средства (ПС) Access их назначение»
1
Раздел 2. Проектирование базы данных
114
Тема 2.1. Концепция проектирования
Содержание учебного материала
2
Типы моделей данных корпоративного хранилища данных. Обеспечение непротиворечивости и целостности данных. Основные этапы разработки БД.
3
Лабораторные работы не предусмотрено
Практические занятия
Анализ предметной области.
Проектирование концептуальной модели БД.
Формализация реляционной модели.
6
Контрольные работы не предусмотрено
-
Самостоятельная работа обучающихся
3.Презентация на тему: «Способы задания таблиц в Access »
4
Тема 2.2. Модели данных. Реляционная модель данных.
Содержание учебного материала
6
Типы взаимосвязей в модели: «один – к- одному», «один- ко -многим» и «многие- ко многим». Реляционный подход к построению модели данных. Особенности реляционной модели и их влияние проектирование баз данных.
3
Изобразительные средства, используемые в ER-моделировании Преобразование взаимосвязи «многие - ко многим» в таблицу перекрестных связей.
Основные операции реляционной алгебры
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Магистрально-модульный принцип построения компьютера. Внутренняя архитектура компьютера; процессор, память. Периферийные устройства: клавиатура, монитор, дисковод, мышь, принтер, сканер, модем, джойстик; мультимедийные компоненты. Программный принцип управления компьютером. Операционная система: назначение, состав, загрузка. Виды программ для компьютеров. Понятие файла, каталога (папки) и правила задания их имен. Шаблон имени файла. Путь к файлу. Ввод команд. Инсталляция программ. Работа с каталогами и файлами.
-
Контрольные работы не предусмотрено
-
Самостоятельная работа обучающихся
4. Реферат на тему: «Способы удаления атрибута в таблице».
3
Тема 2.3. Проектирование базы данных
Содержание учебного материала
16
Понятие, назначение и принцип построения .
Индексирование: понятие индекса, типы индексных файлов. Создание, активация и удаление индекса. Переиндексирование. Сортировка, поиск и фильтрация данных.
Взаимосвязи между таблицами: установление и удаление. Типы ключей. Способы объединения таблиц.
Создание программных файлов. Модульность программ. Область действия переменных.
Типы меню. Работа с меню: создание, модификация, активация и удаление.
Работа с окнами: открытие и закрытие окна, получение справки.
Создание экранной формы: свойства, события и методы. Элементы управления: свойства, события и методы.
Формирование и вывод отчетов
Лабораторные работы
1. Создание базы данных в программе MS Access. Создание таблиц.
2. Создание таблиц.
3. Импорт и экспорт данных
4. Импорт и экспорт данных
5. Создание запросов
6. Создание запросов
7. Создание запросов
8. Создание форм
9. Создание форм
10. Создание форм
11. Создание отчетов
12. Создание отчетов
13. Создание отчетов
14.
15. Создание главной кнопочной формы
30
Практические занятия
Проектирование структуры базы данных.
Нормализация таблиц.
4
Контрольные работы не предусмотрено
-
Самостоятельная работа обучающихся
Выполнение индивидуального проекта тему:
- «Организация работы студенческой библиотеки»;
- «Организация работы университетской типографии»;
- «Организация познавательных экскурсий для школьников»;
- «Организация контроля за успеваемостью ученика»;
- «Расписание занятий»;
25
Тема 2.4.
Физическая организация данных
Содержание учебного материала
6
Механизмы среды хранения и архитектура СУБД
Структура хранимых данных
Виды адресации хранимых записей. Организация связей между хранимыми записями
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
Доклад на тему: « Для каких обьестов Acces можно создавать отчёты»
3
Тема 2.5.
Управление реляционной базой данных
Содержание учебного материала
4
Управление данными – основа администрирования БД. Основная концепция управления данными.
Организация управления данными. Администрирование БД.
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
Сообщение на тему: «Объект – Форма»
2
Раздел 3.
Языки баз данных
14
Тема 3.1
Язык SQL
Содержание учебного материала
6
Язык запросов SQL
Команды языка запросов SQL на изменение: создание файла базы данных, создание таблицы, добавление, редактирование и удаление записей.
Запрос на выборку данных: выборка данных из одной таблицы или нескольких таблиц, с сортировкой и группировкой данных, с условием отбора записей (фильтрацией).
Лабораторные работы
16. Создание SQL-запросов
17. Создание SQL-запросов
18. SQL запросы
19. SQL запросы
8
Практические занятия не предусмотрено
-
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
Презентация на тему: «Процесс создания запрос – выборка»
7
Раздел 4. Использование базы данных
30
Тема 4.1.
Обеспечение функционирования баз данных
Содержание учебного материала
4
Организация системы управления БД
Обобщенная технология работы с БД
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
Реферат на тему: «Опишите процесс установления связи между двумя таблицами в Acces »
2
Тема 4.2. Новые технологии БД
Содержание учебного материала
6
Современные информационные технологии – мониторинг информационных ресурсов;
Применение case – технологий для проектирования БД и приложений;
Современные информационные технологии – распространение данных с широким применением Web – технологий. ГИС для визуализации данных и создания электронных справочных пособий.
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
Доклад на тему: «Смысл новых перспективных направлений развития СУБД»
3
Тема 4.3.
Современные СУБД
Содержание учебного материала
4
Много платформенные СУБД.СУБД, ориентированные на конкретные платформы.
СУБД семейства XBase, Dbase.Перспективы развития БД и СУБД
Лабораторные работы не предусмотрено
-
Практические занятия не предусмотрено
Контрольные работы не предусмотрено
Самостоятельная работа обучающихся
Сообщение на тему: « Направление СУБД – Postgres »
2
Итого:
168
3. условия реализации УЧЕБНОЙ дисциплины
3.1. Требования к минимальному материально-техническому обеспечению
Реализация учебной дисциплины требует наличия учебного кабинета информатики, математики и информатики.
Оборудование учебного кабинета:
Перечень основного оборудования:
сетевой компьютерный класс с выходом в Интернет;
посадочные места по количеству обучающихся;
шкафы для методической литературы;
информационные стенды.
Технические средства обучения:
интерактивная доска- Interwrite ;
проектор-Epson ;
компьютерное рабочее место для преподавателя;
Принтер-HP Deskjet 1280 ;
Сканер-Epson perfection v200 PHOTO.
Описание оборудования на рабочем месте:
Процессортипа Intel® Core™ i5-2400
Процессор с тактовой частотой 3.10Ghz ;
ОЗУ 4,0 GB ;
HDD 2Tb ;
Акустическая система –Genius ;
операционная система - Windows 7x 32 ;
антивируснаяпрограмма -Microsoft security Essentials ;
Программа архиватор-Winrar ;
офисное ПО: текстовый процессор, табличный процессор, программа для создания мультимедийных презентаций-Microsoft office 2007;
система управления базами данных-Microsoft office 2007;
интегрированная среда разработки программного обеспечения-Microsoft office 2007;
система визуального проектирования-Microsoft office 2007.
3.2. Информационное обеспечение обучения
Основные источники:
Матросов В.Л.,Жданов С.А.,Соболева М.Л. Информационные системы в структурно логических схемах.-М.:МПГУ, 2014.-105с.
Фуфаев Э.В., Фуфаев Д.Э. Базы данных-М.: «Академия»,2011-320с.
Дополнительные источники:
Матросов В.Л.,Жданов С.А.,Иванова Н.Ю.,Маняхина В.Г., Костин А.Н. Информатика-М.: «Академия»,2012-336с.
4. Контроль и оценка результатов освоения УЧЕБНОЙ Дисциплины
Контроль и оценка результатов освоения учебной дисциплины осуществляется преподавателем в процессе проведения лабораторных работ, тестирования, а также выполнения обучающимися индивидуальных заданий, курсовой работы.
Результаты обучения
(освоенные умения, усвоенные знания)
Формы и методы контроля и оценки результатов обучения
1
2
Умения:
проектировать реляционную базу данных;
использовать язык SQL для программного извлечения сведений из баз данных.
Комбинированный: лабораторный практикум, рефераты (доклады), отчеты по лабораторному практикуму.
Знания:
основы теории баз данных;
Групповой: рефераты (доклады)
модели данных;
особенности реляционной модели и их влияние проектирование баз данных,
Групповой: рефераты (доклады).
изобразительные средства, используемые в ER-моделировании;
Групповой: рефераты (доклады).
основы реляционной алгебры;
Групповой: рефераты (доклады).
принципы проектирования баз данных,
Групповой: рефераты (доклады).
обеспечение непротиворечивости и целостности данных;
Групповой: рефераты (доклады
средства проектирования структур баз данных;
Групповой: рефераты (доклады
язык запросов SQL
Групповой: рефераты (доклады).
Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
АМУРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
(ГОУВПО «АмГУ»)
КОНТРОЛЬНАЯ РАБОТА
по дисциплине «Информационные системы в экономике»
на тему: «Принципы построения и этапы проектирования баз данных»
Исполнитель
студент группы С – 81 Н.А. Вохмянина
Руководитель
доцент, к. т. н. Д. Г. Шевко
Благовещенск 2010
Введение
1. Принципы построения баз данных
2. Концепции построения баз данных
3. Этапы проектирования баз данных
Библиографический список
ВВЕДЕНИЕ
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.
Традиционно фиксация данных осуществляется с помощью конкретного средства общения, например, с помощью естественного языка на конкретном носителе.
В настоящее время успешное функционирование различных фирм, организаций и предприятий просто не возможно без развитой информационной системы, которая позволяет автоматизировать сбор и обработку данных. Обычно для хранения и доступа к данным, содержащим сведения о некоторой предметной области, создается база данных.
База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.
Под предметной областью принято понимать некоторую область человеческой деятельности или область реального мира, подлежащих изучению для организации управления и автоматизации, например, предприятие, вуз и.т.д.
Система управления базами данных (СУБД) - совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных.
Программы, с помощью которых пользователи работают с БД, называются приложениями.
1. ПРИНЦИПЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ
К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования.
1. Высокое быстродействие (малое время отклика на запрос).
Время отклика - промежуток времени от момента запроса к БД до фактического получения данных. Похожим является термин время доступа - промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их. Часто операции записи, удаления и модификации данных называют операцией обновления.
2. Простота обновления данных.
3. Независимость данных.
4. Совместное использование данных многими пользователями.
5. Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.
6. Стандартизация построения и эксплуатации БД (фактически СУБД).
8. Дружелюбный интерфейс пользователя.
Важнейшими являются первые два противоречивых требования: повышение быстродействия требует упрощения структуры БД, что, в свою очередь, затрудняет процедуру обновления данных , увеличивает их избыточность.
Независимость данных - возможность изменения логической и физической структуры БД без изменения представлений пользователей.
Независимость данных предполагает инвариантность к характеру хранения данных, программному обеспечению и техническим средствам. Она обеспечивает минимальные изменения структуры БД при изменениях стратегии доступа к данным и структуры самих исходных данных. Это достигается «смещением» всех изменений на этапы концептуального и логического проектирования с минимальными изменениями на этапе физического проектирования.
Безопасность данных включает их целостность и защиту.
Целостность данных - устойчивость хранимых данных к разрушению и уничтожению, связанных с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей.
Она предполагает:
1. отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;
2. защиту от ошибок при обновлении БД;
3. невозможность удаления (или каскадное удаление) связанных данных разных таблиц;
4. неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;
5. сохранность данных при сбоях техники (восстановление данных).
Целостность обеспечивается триггерами целостности – специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:
1. введением системы паролей;
2. получением разрешений от администратора базы данных (АБД);
4. формирование видов - таблиц, производных от исходных и предназначенных конкретным пользователям.
Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.
Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).
2. КОНЦЕПЦИЯ ПОСТРОЕНИЯ БАЗЫ ДАННЫХ
Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ).
Первый из них, широко использовавшийся в 80-е годы и потому получивший название классического (традиционного), связан с автоматизацией документооборота (совокупность документов, движущихся в процессе работы предприятия). Исходными и выходными координатами являлись документы, как это видно из примера1.
Использовался следующий тезис. Данные менее подвижны, чем алгоритмы, поэтому следует создать универсальную БД, которую затем можно использовать для любого алгоритма. Однако вскоре выяснилось, что создание универсальной БД проблематично. Господствовавшая до недавнего времени концепция интеграции данных при резком увеличении их объема оказалась несостоятельной. Более того, стали появляться приложения (например, текстовые, графические редакторы), базирующиеся на широко используемых стандартных алгоритмах.
К 90-м годам сформировался второй, современный подход , связанный с автоматизацией управления. Он предполагает первоначальное выявление стандартных алгоритмов приложений (алгоритмов бизнеса в зарубежной терминологии), под которые определяются данные, а стало быть, и база данных. Объектно-ориентированное программирование только усилило значимость этого подхода.
В работе БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру через разные порты) режимы.
Используют восходящее и нисходящее проектирование БД. Первое применяют в распределенных БД при интеграции спроектированных локальных баз данных, которые могут быть выполнены с использованием различных моделей данных. Более характерным для централизованных БД является нисходящее проектирование.
3. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
Проектирование баз данных происходит в четыре этапа.
На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований, определенных в разделе 1, и специфических требований. Для формирования специфических требований обычно используется методика интервьюирования персонала различных уровней управления. Все требования документируются в форме, доступной конечному пользователю и проектировщику БД.
Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.
Сначала выбирается модель БД. Затем создается структура БД, которая заполняется данными с помощью систем меню, экранных форм или в режиме просмотра таблиц БД. Здесь же обеспечивается защита и целостность (в том числе ссылочная) данных с помощью СУБД или путем построения триггеров.
В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации. Цель нормализации – минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией) одной таблицы в две или несколько с последующим использованием при запросах операции навигации. Заметим, что навигационный поиск снижает быстродействие БД, т.е. увеличивает время отклика на запрос. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности.
