Проектирование баз данных. Основные этапы разработки баз данных

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

Основные задачи:

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

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

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

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

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

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

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

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

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

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

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

Нормализация

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

Модели «сущность-связь»

Модель «сущность-связь» (англ. “Entity-Relationship model” ), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма , либо с использованием других графических нотаций (Crow"s Foot , Information Engineering и др.).

Основные преимущества ER-моделей:

• наглядность;
• модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
• ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

• объекты (сущности);
• атрибуты объектов;
• связи между объектами.

Сущность - объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

• типом связи (1:1, 1:N, N:М);
• классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности - обязательный, иначе - необязательный.

Семантические модели

Семантическая модель (концептуальная модель, инфологическая модель) – модель предметной области, предназначенная для представления семантики предметной области на самом высоком уровне абстракции. Это означает, что устранена или минимизирована необходимость использовать понятия «низкого уровня», связанные со спецификой физического представления и хранения данных.

Дейт К. Дж. Введение в системы баз данных. - 8-е изд. - М.: «Вильямс», 2006:

Семантическое моделирование стало предметом интенсивных исследований с конца 1970-х годов. Основным побудительным мотивом подобных исследований (т.е. проблемой, которую пытались разрешить исследователи) был следующий факт. Дело в том, что системы баз данных обычно обладают весьма ограниченными сведениями о смысле хранящихся в них данных. Чаще всего они позволяют лишь манипулировать данными определенных простых типов и определяют некоторые простейшие ограничения целостности, наложенные на эти данные. Любая более сложная интерпретация возлагается на пользователя. Однако было бы замечательно, если бы системы могли обладать немного более широким объемом сведений и несколько интеллектуальнее отвечать на запросы пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя.
[…]
Идеи семантического моделирования могут быть полезны как средство проектирования базы данных даже при отсутствии их непосредственной поддержки в СУБД.

Наиболее известным представителем класса семантических моделей является модель «сущность-связь» (ER-модель).

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М .: «Вильямс», 2006. - 1328 с. - ISBN 0-321-19784-4
• Когаловский М.Р. Перспективные технологии информационных систем. - М .: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4
• Когаловский М.Р. Энциклопедия технологий баз данных. - М .: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
• Кузнецов С. Д. Основы баз данных. - 2-е изд. - М .: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М .: «Вильямс», 2003. - 1436 с. - ISBN 0-201-70857-4
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М .: «Вильямс», 2003. - 1088 с. - ISBN 5-8459-0384-X

См. также

• Методы проектирования

Ссылки

• Модель "сущность-связь" – шаг к единому представлению о данных - Citforum
• Расширение реляционной модели для лучшего отражения семантики - Citforum
• Пособие по проектированию баз данных сайтов "для начинающих"
• Метод проектирования логической структуры реляционной БД без нормализации таблиц

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое "Проектирование баз данных" в других словарях:

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

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

ПРОЕКТИРОВАНИЕ - одна из форм опережающего отражения действительности, процесс создания прообраза (прототипа) предполагаемого объекта, явления или процесса посредством специфич. методов. П. является конкретной формой проявления прогностич. функции управления,… … Российская социологическая энциклопедия

Запрос «БД» перенаправляется сюда; см. также другие значения. База данных представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов),… … Википедия

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

Руководство по проектированию баз данных.

1. Вступление.

SQL – большая тема для повествования и его рассмотрение выходит за рамки данного руководства. Данная статья строго сфокусирована на изложении процесса проектирования баз данных . Позднее, в отдельном руководстве, я расскажу об основах SQL.

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

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

Примеры.

РСУБД.

РСУБД, которую я использовал для создания таблиц примеров – MySQL. MySQL – наиболее популярная РСУБД и она бесплатна.

Утилита для администрирования БД.

После установки MySQL вы получаете только интерфейс командной строки для взаимодействия с MySQL. Лично я предпочитаю графический интерфейс для управления моими базами данных. Я часто использую SQLyog. Это бесплатная утилита с графическим интерфейсом. Изображения таблиц в данном руководстве взяты оттуда.

Визуальное моделирование.

Существует отличное бесплатное приложение MySQL Workbench. Оно позволяет спроектировать вашу базу данных графически. Изображения диаграмм в руководстве сделаны в этой программе.

Проектирование независимо от РСУБД.

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

2. История.

Так выглядели профессионалы в сфере информационных технологий в 70-е. (Слева внизу находится Билл Гейтс).

Текстовые файлы и сегодня все еще используются для хранения малых объемов простой информации. Comma-Separated Values (CSV) - значения, разделённые запятыми, очень популярны и широко поддерживаются сегодня различным программным обеспечением и операционными системами. Microsoft Excel – один из примеров программ, которые могут работать с CSV–файлами. Данные, сохраненные в таком файле могут быть считаны компьютерной программой.

Выше приведен пример того, как такой файл мог бы выглядеть. Программа, производящая чтение данного файла, должна быть уведомлена о том, что данные разделены запятыми. Если программа хочет выбрать и вывести категорию, в которой находится урок "Database Design Tutorial" , то она должна строчка за строчкой производить чтение до тех пор, пока не будут найдены слова "Database Design Tutorial" и затем ей нужно будет прочитать следующее за запятой слово для того, чтобы вывести категорию Software .

Таблицы баз данных.

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

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

История реляционной модели.

Сегодня доступен широкий выбор систем управления базами данных: от небольших десктопных приложений до многофункциональных серверных систем с высокооптимизированными методами поиска. Вот некоторые из наиболее известных систем управления реляционными базами данных (РСУБД):

- Oracle – используется преимущественно для профессиональных, больших приложений.
- Microsoft SQL server – РСУБД компании Microsoft. Доступна только для операционной системы Windows.
- Mysql – очень популярная РСУБД с открытым исходным кодом. Широко используется как профессионалами, так и новичками. Что еще нужно?! Она бесплатна.
- IBM – имеет ряд РСУБД, наиболее известна DB2.
- Microsoft Access – РСУБД, которая используется в офисе и дома. На самом деле – это больше, чем просто база данных. MS Access позволяет создавать базы данных с пользовательским интерфейсом.
В следующей части я расскажу кое-что о характеристиках реляционных баз данных.

3. Характеристики реляционных баз данных.

Использование ключей.

Используя структурированный язык запросов (SQL), данные из разных таблиц, которые связаны ключом, могут быть выбраны за один раз. Для примера вы можете создать запрос, который выберет все заказы из таблицы заказов (orders), которые принадлежат пользователю с идентификатором (id) 3 (Mike) из таблицы пользователей (users). О ключах мы поговорим далее, в следующих частях.

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

Отсутствие избыточности данных.

Ограничение ввода.

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

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

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

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

Поддержание целостности данных.

Назначение прав.

Структурированный язык запросов (SQL).

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

Переносимость.

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

В следующей части подробнее рассмотрим первичные ключи.

ВВЕДЕНИЕ

1.2 База данных

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

1.4 Модель данных

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

2. ПОСТАНОВКА ЗАДАЧИ

3. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РЕЛЯЦИОННЫХ БАЗЫ ДАННЫХ

3.1 Реляционная алгебра

3.1.1 Общая интерпретация реляционных операций

3.1.2 Замкнутость реляционной алгебры и операция переименования

3.1.3 Особенности теоретико-множественных операций реляционной алгебры

3.2 Реляционное исчисление

3.2.1 Кортежные переменные и правильно построенные формулы

3.2.2 Целевые списки и выражения реляционного исчисления

3.2.3 Реляционное исчисление доменов

3.3 Целостность данных

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

4. РАЗРАБОТКА БАЗЫ ДАННЫХ

4.1 Предметная область базы данных

4.2 Построение инфологической модели

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

5. РАЗРАБОТКА ПРИЛОЖЕНИЯ-КЛИЕНТА

5.1 Обоснование выбора среды программирования

5.2 Средства Delphi для работы с базами данных

5.3 Реализация приложения

5.3.1 Общее описание форм и модулей

5.3.2 Форма MainForm и модуль Main

5.3.3 Модуль данных DataModule1 и модуль DBUnit

5.3.4 Форма EditForm и модуль Edit

5.3.5 Форма DeleteForm и модуль Delete

5.3.6 Форма FindForm и модуль Find

5.3.7 Форма FilterForm и модуль Filter

5.3.8 Форма DirSourceForm и модуль DirSource

5.3.9 Форма PathForm и модуль Path

5.3.10 Форма UserForm и модуль User

5.3.11 Форма AboutBox и модуль About

5.3.12 Модуль Files

6. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

6.1 Предметная область базы данных и её разработка

6.2 Разработка сетевого графика работ проведения НИР

6.3 Расчет сметы затрат на проведение НИР

7. ОХРАНА ТРУДА

7.1 Общие вопросы охраны труда

7.2 Производственная санитария

7.3 Техника безопасности

7.4 Эксплутационные меры

7.5 Пожарная безопасность

7.6 Охрана окружающей среды

8. ГРАЖДАНСКАЯ ОБОРОНА

СПИСОК ССЫЛОК

ПРИЛОЖЕНИЯ

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

Целью данной дипломной работы является разработка удалённой базы данных и приложения-клиента для доступа к электронным источникам литературы, содержащихся на жёстком диске сервера предприятия в виде файлов и пакетов фалов (текстовых документов различных типов, гипертекста HTML, исполняемых файлов и др.). Архитектура клиент-сервер, используемая при реализации поставленной задачи на данный момент является наиболее прогрессивной. Она даёт возможность разделить задачу на две подзадачи: разработка собственно удалённой базы данных, физически расположённой на сервере и управляемой СУБД, и приложения, осуществляющего доступ к данной базе данных при помощи SQL-запросов и располагающееся на рабочих станциях пользователей сети. При такой реализации нагрузка также распределяется между сервером и рабочими станциями, что позволяет увеличить скорость работы программы.

Для управления базой данных была выбрана СУБД InterBase 6.0 фирмы Borland. Для разработки клиентской части приложения использовалась среда программирования Borland Dalphi 7.0 Eneterprise Edition, предоставляющая удобные средства для быстрого и наглядного создания подобных приложений.

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

1. АНАЛИТИЧЕСКИЙ ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ

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

Система баз данных – это компьютеризированная система хранения записей, т.е. компьютеризированная система, основное назначение которой – хранить информацию, предоставляя пользователям средства её извлечения и модификации .

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

1) компактность;

2) скорость;

3) низкие трудозатраты;

4) актуальность;

5) централизованное управление данными;

6) независимость данных.

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

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

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

К аппаратному обеспечению системы относят следующее:

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

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

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

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

Таблица «Счет» Таблица «Товар» Таблица «Товар по счету» Таблица «Товарные группы» Лабораторная работа № 2. Разработка запросов отбора данных и вычислений Цель работы приобретение навыков в описании запросов к базе данных на языке QBE (Query by Example). Выборка неоплаченных счетов Результат выполнения: Выборка поставок Результат выполнения: Поиск...

Проекта 1. Введение. Целью данного курсового проекта является структурирование данных и разработка пользовательского интерфейса. В курсовом проекте рассмотрены следующие теоретические вопросы и практические задания: ü проведен системно-комплексный анализ выбранного объекта автоматизации ü разработана структура пользовательского интерфейса автоматизированной системы...

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

Я предполагаю, что SQL вы знаете. То есть, объяснять, что такое таблицы, строки, индексы, первичные ключи и ссылочная целостность, не требуется. Если это не так, боюсь, я вынужден отправить вас к соответствующей литературе. Благо, ее сейчас очень много.

Рисуем диаграмму

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

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

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

Генерируем SQL и скармливаем его СУБД

Нетрудно заметить, что данная диаграмма легко отображается в код для создания схемы базы данных на языке SQL. В DbSchema сгенерировать SQL можно, сказав Schema → Generate Schema and Data Script. Затем полученный скрипт можно скормить используемой вами СУБД:

cat music.sql | psql -hlocalhost test_database test_user

Я использовал PostgreSQL. Информацию о том, как установить эту СУБД, вы найдете в этой заметке .

Итак, чем же я руководствовался при проектировании схемы?

Нормальные формы

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

Грубо говоря, таблица находится в первой нормальной форме (1НФ), если на пересечении любой строки и любого столбца в таблице находится ровно одно значение. В современных РСУБД это условие всегда выполняется. Даже если СУБД поддерживает множества или массивы, на пересечении строки и столбца хранится ровно одно значение типа множество или массив. Но в таблице (user varchar(100), phone integer) не может быть строки alex - 1234, 5678 . В 1НФ может быть только две сроки — alex - 1234 и alex - 5678 .

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

Таблица находится в третьей нормальной форме, если она находится в 2НФ и ни один неключевой атрибут не находится в транзитивной функциональной зависимости от первичного ключа. Например, рассмотрим таблицу (employee varchar(100) primary key, department varchar(100), department_phone integer) . Очевидно, что она находится в 2НФ. Но телефон отдела находится в транзитивной функциональной зависимости от имени сотрудника, так как сотрудник однозначно задает отдел, а отдел однозначно задает телефон отдела. Для приведения таблицы в 3НФ нужно разбить ее на две таблицы — employee - department и departmnet - phone .

Легко видеть, что нормализация уменьшает избыточность базы данных и препятствует внесению случайных ошибок. Например, если оставить таблицу из последнего примера в 2НФ, то можно по ошибке прописать одному и тому же отделу разные телефоны. Или рассмотрим компанию с пятью отделами и 1000 сотрудниками. Если у отдела поменялся номер телефона, то для его обновления в базе данных в случае 2НФ потребуется просканировать 1000 строк, а в случае с 3НФ только пять.

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования

«Российский экономический университет им. Г.В. Плеханова»

Факультет математической экономики и информатики

Кафедра информатики

КОМПЛЕКСНАЯ МЕЖДИСЦИПЛИНАРНАЯ

КУРСОВАЯ РАБОТА

По дисциплинам: «Базы данных»,

«Структуры данных и алгоритмы»

На тему: «Разработка базы данных библиотеки»

Выполнила:

студентка 427 группы

очной формы обучения

факультета математической экономики и информатики

Янушкевич Валерия Вадимовна

Научный руководитель:

Доцент, к.т.н.

Мосьяков Владимир Евгеньевич

Москва 2015

ВВЕДЕНИЕ

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

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

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

Цель работы : разработать базу данных "Библиотека".

Задачи работы:

Спроектировать базу данных;

Установить связи между объектами предметной области;

Автоматизировать обновление и модификацию базы данных.

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Анализ предметной области

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

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

Сформулируем требования к нашей работе

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

• Прием новых читателей;
• Учет новых печатных изданий;
• Обеспечение соблюдения правил пользования литературой;

1.2. Разработка контекстной диаграммы

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

Рис.1 Контекстная диаграмма функционирования библиотеки нотация IDEF 0

На вход информационной системы поступают:

• Книги;
• Люди;
• Запросы.

На выходе информационной системы получаются:

• Книги;
• Отказы читателей;
• Читатель.

Процессами управления являются:

• Нормативные акты;
• Особенности СУБД.

Для полноценной работы системы необходим квалифициованный персонал.

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

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

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

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

1.3. Диаграммы декомпозиций

Вся библиотечная система состоит из трёх основных частей, а именно:

• Ведение каталога;
• Поисковой системы;
• Системы формирования заказов.

Взаимодействие этих блоков (подсистем) показано на рис.2.

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

Рис.2 Взаимодействие основных компонентов системы

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

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

1.4. Ведение каталога

Подсистема ведения каталогов состоит из двух основных элементов: ведение каталога книг; ведение каталога читателей.

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

Рис.3 Подсистема ведения каталогов

1.5. Ведение каталога книг

Как и любой другой каталог, каталог ведения книг имеет такие основные компоненты:

• Формирование сведений о книге;
• Пополнение БД;
• Определение книг на склад.

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

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

Каждый компонент модуля ведения каталога книг рис.4., распадается на составные части, которые наглядно показаны на рис.5, рис.6, рис7.

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

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

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

1.6. Ведение каталога читателей

Устройство этого элемента системы очень схоже с «ведением каталога книг» рис.4, за одним исключением у него отсутствует блок «определения книг на склад», он здесь и не нужен. Так же блок «Пополнения БД читателей» видоизменён, если сравнивать его с «Пополнением БД» рис.10. Элемент «Сбор сведений» представлен на рис.9. Основные блоки «модуля ведения каталога читателей» представлены на рис.8.

Люди обращаются в библиотечную систему, что бы взять книгу. В этом блоке система собирает информацию о человеке рис.9, является ли он читателем этой библиотеки. Если он приходит в первый раз, то на него быстро формируется соответствующая учётная запись в базе данных рис.10, и с ним работают как с читателем, предоставляя ему возможность взять на чтение книгу. Информация о взятой читателем книги заносится в базу данных.

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

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

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

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

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

1.7. Поисковая система

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

• Принятие запроса рис.13;
• Использование СУБД (по обработке запроса) рис.14;
• Формирование удобного вида отчёта рис.15.

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

1.8. Система формирования заказов

Сам процесс формирования заказа имеет в себе такие важные компоненты:

• Регистрация заказа рис.17;
• Формирование заказа рис.18;
• Оформление заказа рис.19;
• Выдача товара рис.20.

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

1.9. Диаграммы дерева узлов

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

Рис.21 Диаграмма дерева узлов библиотечной ИС глубины 4

Модель базы данных

Разработанная логическая модель базы данных представлена на рис.22, в ней описаны основные объекты БД и отношения.

Рис. 22 Логическая модель базы данных

2. ОСНОВНАЯ ЧАСТЬ

2.1.Технология проектирования баз данных

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

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

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

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

2.2.Определение сущностей

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

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

• читатель;
• печатное издание;
• выдача;
• каталог;
• читатель-задолжник;

2.3. Определение взаимосвязей между сущностями и создание модели данных

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

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

Определим для вышеперечисленных сущностей взаимосвязи.

Полученная после этого информационная модель представлена на рисунке 4.

Рисунок 25 – Информационная модель на втором этапе

Все связи между объектами (рисунок 6) являются связями «один ко многим», то есть одной записи данных первого объекта (основного) соответствует несколько записей второго объекта (подчиненного).

2.4. Задание первичных и альтернативных ключей, определение атрибутов сущностей

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

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

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

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

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

Таблица 1 - Первичные, альтернативные ключи и атрибуты

2.5. Приведение модели к требуемому уровню нормальной формы

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

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

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

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

2.6. Описание физической модели

Расставим связи между таблицами (рисунок 5).

Рисунок 26– Схема данных

Все таблицы связаны между собой связью типа "Один-ко-многим". На примере таблиц "Издательства" и "Города" это означает, что одно издательство может иметь только один город, но в таблице "Издательства" может присутствовать множество записей таблицы "Города". Т.е. разные издательства могут иметь одинаковые названия городов.

Отчет по схеме:

Рисунок 27 – Схема данных

Аналогично связаны между собой остальные таблицы.

Основные характеристики используемой СУБД

В результаты мы получили СУБД, обладающую рядом характеристик.

Разработанная СУБД позволяет выполнять простейшие операции с данными:

Добавлять в таблицу одну или несколько записей;

Удалять из таблицы одну или несколько записей;

Обновлять значения некоторых полей в одной или нескольких записях;

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

Разработанная СУБД организует хранение информации таким образом, чтобы ее было удобно:

Просматривать;

Пополнять;

Изменять;

Искать нужные сведения,

Делать любые выборки.

2.7. Разработка меню, форм, инструментальных панелей и др.

Разработаем формы для каждой из таблиц и занесем в них данные.

Рисунок 29 – Форма "Города"

Рисунок 30 – Форма "Издательства"

Рисунок 31– Форма "Информация о книге"

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

Рисунок 33 – Форма "Информация о читателе"

Рисунок 34– Форма "Бронирование книг"

В данной форме требуется ввести либо "Шифр книги" либо выбрать «Код читательского билета». Второе поле база данных установит самостоятельно.

Рисунок 35– Форма "Выдача книг"

Создадим главную кнопочную форму.

Рисунок 36 – Форма "Главная кнопочная форма"

Разработка запросов

Разработаем запросы.

1) Вывод сведений о книгах, взятых определенным читателем

SELECT [Выдача книг].[Код читательского билета], [Выдача книг].[Шифр книги], [Информация о книге].Название, Издательства.Наименование, [Выдача книг].[Дата выдачи книги], [Выдача книг].[Дата возврата книги]

FROM ([Информация о читателе] INNER JOIN ((Издательства INNER JOIN [Информация о книге] ON Издательства.[Код издательства] = [Информация о книге].[Код издательства]) INNER JOIN [Бронирование книг] ON [Информация о книге].[Шифр книги] = [Бронирование книг].[Шифр книги]) ON [Информация о читателе].[Номер билета] = [Бронирование книг].[Код читательского билета]) INNER JOIN [Выдача книг] ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета];

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

Рисунок 38 – Запрос "Сведения о читателях, у которых находится определенная книга"

Данный запрос, описанный в SQL:

SELECT [Информация о книге].[Шифр книги], [Информация о книге].Название, [Выдача книг].[Дата выдачи книги], [Выдача книг].[Дата выдачи книги], [Информация о читателе].Фамилия, [Информация о читателе].Имя, [Информация о читателе].Отчество

FROM [Информация о читателе] INNER JOIN ([Информация о книге] INNER JOIN [Выдача книг] ON [Информация о книге].[Шифр книги] = [Выдача книг].[Шифр книги]) ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета];

Данный запрос, описанный в SQL:

SELECT [Информация о читателе].[Номер билета], [Информация о читателе].[Фамилия], [Информация о читателе].[Имя], [Информация о читателе].[Отчество], [Информация о читателе].[Телефон], [Информация о читателе].[Адрес]

FROM [Информация о читателе];

Данный запрос, описанный в SQL:

Данный запрос, описанный в SQL:

SELECT [Информация о книге].[Код раздела]

FROM [Информация о книге]

WHERE ((([Информация о книге].[Код раздела])=1)) OR ((([Информация о книге].[Код раздела])=3));

Данный запрос, описанный в SQL:

SELECT [Информация о читателе].[Номер билета], [Выдача книг].[Дата возврата книги]

FROM [Информация о читателе] INNER JOIN [Выдача книг] ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета]

GROUP BY [Информация о читателе].[Номер билета], [Выдача книг].[Дата возврата книги];

Данный запрос, описанный в SQL:

SELECT [Информация о книге].[Шифр книги], [Информация о книге].[Год издания]

FROM [Информация о книге]

WHERE ((([Информация о книге].[Год издания])>"#2000#"));

Рисунок 44 – Запрос на выдачу не более 5 книг и сданную литературу до 01.01.2014 г.

Данный запрос, описанный в SQL:

SELECT [Информация о книге].Количество, [Информация о читателе].Фамилия, [Выдача книг].[Дата возврата книги]

FROM [Информация о книге] INNER JOIN ([Информация о читателе] INNER JOIN [Выдача книг] ON [Информация о читателе].[Номер билета] = [Выдача книг].[Код читательского билета]) ON [Информация о книге].[Шифр книги] = [Выдача книг].[Шифр книги]

WHERE ((([Информация о книге].Количество)>"5") AND (([Выдача книг].[Дата возврата книги])>#1/1/2014#));

Данный запрос, описанный в SQL:

SELECT Задолжники.Фамилия, Задолжники.Имя, Задолжники.Отчество, Задолжники.[Дата выдачи книги]

FROM Задолжники

WHERE (((Задолжники.[Дата выдачи книги])<#1/1/2013#));

ЗАКЛЮЧЕНИЕ

Разработанная в ходе выполнения курсового проекта база данных «Библиотека», является актуальной на сегодняшний день и имеет большую практическую значимость. БД удовлетворяет современным требованиям учёта литературы и предоставляет все услуги абонентам.

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Сеннов А. Access 2010. Учебный курс– СПб.: Питер, 2010. – 288с.:ил.
2. Рубин А.А., Клеандрова И.А., Прокди Р.Г. Самоучитель Access 2007. 100% результат уверенной работы– СПб.: Наука и Техника, 2011. – 400с.:ил.
3. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2007 – 400 с.: ил.
4. Кумскова И.А. Базы данных: учебник. – М.: КНОРУС, 2012. – 488 с.
5. Игорева, Е.Л., Основы алгоритмизации и программирования (3-е издание)./ И.И. Попов, О.Л. Игорева - М.: Инфа-М, 2013
6. Петгольц, Ч. Программирование #. В 3-х томах. Том 2. Пер. с англ./ Ч. Петгольц - М.: Издательско-торговый дом «Русская редакция», 2012.
7. Петгольц, Ч. Программирование. В 3-х томах. Том 3 Пер. с англ./ Ч. Петгольц - М.: Издательско-торговый дом «Русская редакция», 2012.
8. Глушаков С.В., Ломотько Д.В. Базы данных: Учебный курс. - Харьков: Фолио; Ростов н/Д: Феникс; Киев: Абрис, 2010.
9. Мишенин А.И. Теория экономических информационных систем - М.: Финансы и статистика, 2010.
10. Дженнингс Р.; Использование Microsoft Office Access 2014 - М: Издательский дом «Вильямс», 2014. - 1312 с.

выдача книг

Задолжники

итатели

Ведется учет

Книги (каталог книг)

Могут получать книги

Раздел

входят

Поиск книги

Может быть

Может

Осуществлять