Тема 2

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

Проектирование БД.

Источник информации:

Учебник по информатике 12 класс, стр. 63-75

Видеоматериал

Учебный материал

Вопросы:

1. Понятие модели и информационных систем.
2. Понятие БД и СУБД.
3. Классификация БД.
4. Модели БД: реляционная, иерархическая и сетевая.
5. Фазы жизненного цикла БД.
6. Этапы проектирования БД.
7. Типы связей между таблицами в многотабличной БД.
8. Этапы создания БД.

 Модель – это некий новый упрощенный объект, отражающий некоторые характеристики оригинала. Модели бывают материальные и информационные. Примеры материальных моделей: глобус, карта, игрушка, манекен. Информатика занимается изучением информационных моделей. Информационная модель базируется на данных об объекте. Эти данные должны быть всегда упорядочены определенным образом. Такие системы данных называются структурами данных. Таким образом, структурированные системы данных, хранящиеся на каких-либо носителях, называются структурами данных.

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

Информационная система (ИС) — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию.

Информационные системы
Назначение ИС			Состав ИС
Хранение, поиск, обработка, передача больших объемов информации для определенной области применения			Структура данных	Средства системного обеспечения		Средства прикладного обеспечения
Области приложения			Техническая база
Справочно-информационная	Управленческая, принятие решений	Обучение и др.	На одном компьютере		На базе компьютерной сети
Разновидности информационных систем
ИПС – информационно-поисковая система	САУ – система автоматического управления	АСУ – автоматизированные системы управления	ГИС – геоинформационные системы	ЭС – экспертные системы		Системы обучения и др.

Информационная система состоит из двух частей:

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

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

Примеры баз данных: записная книжка, классный журнал, справочники.

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

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

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

В настоящее время существует несколько видов СУБД. Наиболее известными и популярными СУБД являются Access, FoxPro и Paradox. Каждая из этих систем обладает своими достоинствами и недостатками. Остановим свой выбор на базе данных Access, которая входит в программный продукт Microsoft Office и является наиболее доступной для изучения. Прежде чем переходить к работе по созданию базы данных на компьютере, необходимо перейти от информационной модели данных, к модели, ориентированной на компьютерную реализацию.

Базы данных классифицируются по разным признакам.

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

Классификация по способу хранения данных делит БД на: централизованные и распределенные. Вся информация в централизованной БД хранится на одном компьютере. Это может быть автономный ПК или сервер сети, к которому имеют доступ пользователи-клиенты. Распределенные БД используются в локальных и глобальных компьютерных сетях. В таком случае разные части базы хранятся на разных компьютерах.

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

  

Реляционная модель

Термин «реляционный» (от латинского relatio — отношение) указывает, прежде всего, на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей. В простейшем случае она представляет собой двухмерный массив или двухмерную таблицу, а при создании сложных информационных моделей составит совокупность взаимосвязанных таблиц.

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

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

Главный ключ – поле или совокупность полей, значение которого не повторяется у разных записей.

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

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

Первичный ключ — это одно или несколько полей, однозначно идентифицирующих запись. Если первичный ключ состоит из одного поля, он называется простым, если из нескольких полей — составным ключом.

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

Реляционная модель БД имеет следующие свойства:

1)      Каждый элемент таблицы — один элемент данных.

2)      Все столбцы в таблице являются однородными, т. е. имеют один тип (числа, текст, дата  т. д.).

3)      Каждый столбец (поле) имеет уникальное имя.

4)      Одинаковые строки в таблице отсутствуют.

5) Порядок следования строк в таблице может быть произвольным и может характеризоваться количеством полей, количеством записей, типом данных.

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

1)      сортировку данных (например, по алфавиту);

2)      выборку данных по группам (например, по датам рождения или по фамилиям);

3)      поиск записей (например, по фамилиям) и т. д.

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

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

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

Узел — информационная модель элемента, находящегося на данном уровне иерархии.

Рассмотрим иерархическую модель на примере базы данных «Школа». С точки зрения иерархической модели, она должна принять следующий вид: в состав школы входят классы; параллельные классы делятся по буквам, в состав каждого класса входят конкретные ученики.

Свойства иерархической модели БД:

1)      несколько узлов низшего уровня связано только с одним узлом высшего уровня;

2)      иерархическое дерево имеет только одну вершину (корень), не подчиненный никакой другой вершине;

3)      каждый узел имеет свое имя (идентификатор).

Существует только один путь от корневой записи к более частной записи данных. В примере с базой данных «Школа» следует обратить внимание на то, что каждый узел в этой схеме удобно описывать в виде таб­лиц, т. е. применять реляционную модель. Таким образом, базы данных можно описывать совокупностью нескольких моделей.

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

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

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

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

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

Можно выделить две фазы жизненного цикла БД:

                            I.  проектирование базы данных;

                         II.   эксплуатация базы данных.

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

Анализ предметной области (Системный анализ)

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

Цель: Сбор данных (ничего не потерять!); Анализ документов и информационных потоков.

Существует два подхода к выбору состава и структуры предметной области:

Функциональный подход, который реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания потребностей которых создается БД.

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

Результат:

* подробное описание информации об объектах предметной области и информационных процессов;

* конкретные задачи, которые будут решаться данной БД с кратким описанием алгоритма решения;

* описание выходных документов, которые должны генерироваться в системе;

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

Информационно-логическое (концептуальное) проектирование

Рассматривается с позиций администратора предприятия.

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

Результат: построение независимой от СУБД информационной структуры путем объединения информационных требований пользователей. Эта структура называется инфологическая (семантическая) модель (ИЛМ).

Логическое проектирование

Цель: Выбор СУБД; Разработка СУБД - ориентированной схемы данных.

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

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

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

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

Физическое проектирование

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

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

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

Существует две причины для создания связей между таблицами:

1.      поддержание ссылочной целостности и

2.      задание способа выборки данных из нескольких таблиц.

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

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

1.      один-к-одному (1:1)

2.      один-ко-многим (1:∞)

3.      много-ко-многим (∞:∞).

Связь типа «один-к-одному» (1:1)

При этом типе связи каждой записи в одной таблице соответствует не более одной записи в связанной таблице. Этот вид связи встречается довольно редко. В основном в тех случаях, когда часть информации об объекте либо редко используется, либо является конфиденциальной (такая информация хранится в отдельной таблице, которая защищена от несанкционированного доступа).

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

Связь типа «один-ко-многим» (1:∞)

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

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

Связь типа «много-ко-многим» (∞:∞)

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

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

Макет БД

1. Определение цели и задач создания БД.

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

2. Определение состава таблиц, которые должна содержать БД.

Таблицы, которые должна выдавать БД (отчеты, выходные формы и др.) не всегда дают полное представление о её структуре. При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге.

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

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

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

3. Определение необходимых в таблице полей.

Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы.

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

При разработке полей для каждой таблицы необходимо помнить:

1)      Каждое поле должно быть связано с темой таблицы.

2)      Не рекомендуется включать в таблицу данные, которые являются результатом.

3)      В таблице должна присутствовать вся необходимая информация.

4)      Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).

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

4. Определение связей между таблицами

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

Таблицы MS Access

5. Обновление структуры БД

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

Формы MS Access

6. Добавление данных и создание других объектов БД

Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные. Затем можно создавать любые запросы, формы, отчеты, макросы и модули.

Запросы и отчеты MSAccess

7. Использование средств анализа в Microsoft Access

В Microsoft Access существует два инструмента для усовершенствования структуры БД. Мастер анализа таблиц исследует таблицу, в случае необходимости предлагает новую ее структуру и связи, а также переделывает ее. Анализатор быстродействия исследует всю БД, дает рекомендации по ее улучшению, а также осуществляет их.

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

Вопросы для самопроверки:

1. Что такое модель?
2. Какова цель создания моделей?
3. Какие виды моделей бывают?
4. Что такое информационная система?
5. Из чего состоит информационная система?
6. Что такое база данных?
7. Где и для чего применяются базы данных?
8. Как классифицируют базы данных?
9. Какие виды БД популярнее? Почему?
10. Что такое СУБД?
11. Цель СУБД?
12. Какими свойствами должна обладать реляционная БД?
13. Для чего в реляционной БД применяется ключ?
14. Что в реляционной БД называется полем, а что записью?
15. Каковы свойства иерархической БД?
16. Чем сетевая БД отличается от иерархической БД?
17. Как спроектировать БД? Какие выделают этапы проектирования?
18. В реляционной БД устанавливаются между таблицами связи. Какие это типы связей?
19. Как понять принцип соединения один ко одному ?
20. Как понять принцип связи один ко многим?
21. Этапы проектирования и этапы создания - это одно и то же или нет? Докажите свою точку зрения.