Примеры базы данных

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

Этап начальной разработки

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

Концептуальное проектирование базы данных

  • анализ требований к базе данных, выявление представлений конечных пользователей и требований к обработке транзакций;
  • определение сущностей, атрибутов и связей;
  • разработка ER-диаграмм (от ER — Entity-Relationship — Сущность-Связь);
  • нормализация;
  • проверка модели данных, выявление основных процессов (правила ввода, обновления и удаления данных);
  • проверка отчётов, запросов, представлений, целостности, совместного использования и безопасности.

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

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

В каждой из аптек регистрируется покупка каждой единицы препарата и все покупки, совершённые одним клиентом в одной аптеки в один момент времени, прикрепляются к корзине покупок.

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

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

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

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

  • Аптека (Pharmacy);
  • Группа препаратов(Group);
  • Наличие (Availability);
  • Дефицит (Deficit);
  • Сотрудник (Employee);
  • Клиент (Client);
  • Корзина (Basket);
  • Покупка (Buying).

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

Примеры базы данных

Опишем отношения между сущностями.

Сущность «Аптека» связана отношением «Имеет» «один ко многим» с сущностью «Наличие», отношением «Имеет» «один ко многим» с сущностью «Дефицит», отношением «Имеет» «один ко многим» с сущностью «Покупка», отношением «Работает» «один ко многим» с сущностью «Сотрудник».

Сущности «Наличие» и «Дефицит» связаны отношениями «Включает» «многое к одному» с сущностью «Препарат».

Сущность «Препарат» кроме упомянутых связей связано отношением «Включает» «многое к одному» с сущностью «Группа» и отношением «Включает» «один ко многим» с сущностью «Покупка».

Сущность «Покупка» кроме упомянутых связей связана отношением «Включает» «многое к одному» с сущностью «Корзина».

Сущность «Сотрудник» кроме упомянутой связи с сущностью «Аптека» связан отношением «Регистрирует» «один ко многим» с сущностью «Корзина».

Сущность «Клиент» связан отношением «Имеет» «один ко многим» с сущностью «Корзина».

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

Все 9 таблиц базы данных находятся по меньшей мере в первой нормальной форме, так как:

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

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

Следовательно, все таблицы находятся и во второй нормальной форме.

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

  • доступность выбираемого в селекторе препарата в выбираемой в селекторе аптеке на данный момент времени;
  • группы препаратов, которых нет в выбираемой в селекторе аптеке на данный момент времени;
  • аптеки, в которых есть дефицит любого препарата по введённой дате;
  • покупки препаратов, которые есть на витринах аптек по введённой дате с указанием препаратов и аптек;
  • клиенты, совершившие покупки в выбранной в селекторе аптеке по введённой дате.
  • о количестве покупок со списком аптек по введённой дате с указанием сумм;
  • о продажах выбранного препарата во всех аптеках по введённой дате;
  • о проданных препаратах стоимостью более 150 рублей по введённой дате;
  • о препаратах, которые есть на витрине во всех аптеках;
  • о клиентах, зарегистрированных в определённый интервал времени.

Поделиться с друзьями

Иерархическая база данных — это. Модели, примеры

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

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

Примеры базы данных

Как известно, различают четыре вида посторения БД:

  • Реляционные — табличные СУБД, где информация представлена в виде строк-столбцов. По этому принципу строятся базы данных в «Аксесе», к примеру.
  • Объектно-ориентированные — тесно связаны с ООП (программированием, в котором идет работа с объектами), и это их главный плюс, но, учитывая их небольшую производительность, они пока значительно уступают в распространенности реляционным.
  • Гибридные — СУБД, вмещающие в себе сразу два указанных выше вида.
  • Иерархические — объект внимания данной статьи. Это БД, характеризирующиеся древообразной структурой.

Наиболее известным примером иерархической базы данных является продукт, созданный компанией IBM («АйБиЭм»), под названием Information Management System (переводится как «Информационная система управления»), сокращенно IMS. Первая версия IMS вышла еще в прошлом, двадцатом веке, в шестьдесят восьмом году. Она используется для хранения и контроля данных и поныне.

Принцип построения иерархической модели

Примеры базы данных

Иерархическая модель данных строится по следующему принципу:

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

Применение иерархической структуры данных

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

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

Примеры базы данных

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

Основные операции над БД, построенными на иерархической модели

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

  • поиск по базе данных того или иного элемента;
  • переход по базе данных — от дерева к дереву;
  • переход по дереву — от ветви к ветви;
  • соответственно, переход по ветвям — поэлементно;
  • работа с записями: вставка новой и/или удаление текущей, копирование, вырезание и т. д.

Обобщенное описание структуры

Термин «древовидная» для описания структуры упоминается в этой статье уже далеко не единожды. Пора рассказать, откуда он произошел. Все потому что иерархическая база данных — это такая БД, которая использует тип данных «дерево». Рассмотрим подробнее, что он из себя представляет.

Это составной тип: в каждый из элементов (узлов) вкладывается несколько последующих (один или более). А начинается все с одного корневого элемента. Суть в том, что каждый из кусочков типа «дерево», является подтипом, тоже «деревом». Много-много разветвленных, и все также упорядоченных структур.

Примеры базы данных

Элементарные типы могут быть простыми и составными, но по существу это всегда записи. Но в простом записи присутствует один тип данных, а в составном — целая их совокупность.

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

Наполнение БД

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

Достоинства

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

Примеры базы данных

Иерархическая модель идеальна для применения ее для упорядоченной информации.

Недостатки

Однако те же особенности рассматриваемых СУБД, которые стали их основными достоинствами, определяют также и их недостатки. К примеру, громоздкость и сложность логических связей — опытному специалисту при работе с ранее неизвестной базой будет трудно разобраться, а простой пользователь и вовсе в ней «заблудится». Эта сложность понимания приводит к тому, что на самом деле не так много СУБД построены на иерархической модели. Примером иерархической базы данных является, кроме уже описанного продукта компании «АйБиЭм», «Ока» и МИРИС (производство России), а также Data Edge и Team-UP (от зарубежных корпораций).

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

Примеры базы данных

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

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

Применение в ЭВМ

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

Сетевые базы данных

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

Почему мы вновь вспомнили о классификации? Поскольку, в отличие от реляционной, сетевая БД имеет с иерархической схожие черты.

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

Иерархия и реляционность

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

Примеры базы данных

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

Примеры базы данных

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

Примеры базы данных

Топ-10 разорившихся звезд Оказывается, иногда даже самая громкая слава заканчивается провалом, как в случае с этими знаменитостями.

Примеры базы данных

Время бить тревогу: 11 признаков, что ваш партнер вам изменяет Измена — это самое страшное, что может случиться в отношениях двух людей. Причем, как правило, все происходит не как в фильмах или сериалах, а гораздо.

Примеры базы данных

Как выглядеть моложе: лучшие стрижки для тех, кому за 30, 40, 50, 60 Девушки в 20 лет не волнуются о форме и длине прически. Кажется, молодость создана для экспериментов над внешностью и дерзких локонов. Однако уже посл.

Примеры базы данных

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

Примеры базы данных

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

Примеры базы данных
Главная | О нас | Обратная связь

Пример проектирования базы данных «СКЛАД»

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

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

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

Характеристики полей этих таблиц представлены в таблицах 1.1 – 1.3.

При вводе данных, очевидно, следует сначала заполнить таблицы «ПОКУПАТЕЛИ» и «ПОСТАВЩИКИ» для того, чтобы значения соответствующих полей в таблице «ТОВАРЫ» («Клиент» и «Поставщик») можно было взять уже из готовых таблиц.

Таблица 1.1 — Характеристики полей таблицы «ТОВАРЫ»

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

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

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

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

1. Определение назначения базы данных.

2. Принятие решения о том, какие исходные данные база данных должна содержать.

3. Определение исходных таблиц базы данных.

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

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

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

7. Создание форм, отчетов и запросов для операций с введенными данными.

Определение назначения базы данных

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

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

Выбор информации, включаемой в базу

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

1. Автор (фамилия и имя каждого автора книги).

2. Название книги.

3. Место издания (город).

4. Издательство (название издательства).

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

1. Номер комнаты (помещения для хранения книг).

2. Номер стеллажа в комнате.

3. Номер полки на стеллаже.

4. Номер (инвентарный номер книги).

5. Дата приобретения.

6. Дата размещения конкретной книги на конкретном месте.

7. Дата изъятия книги с установленного места.

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

1. Номер читательского билета (формуляра).

2. Фамилия читателя.

4. Отчество читателя.

5. Адрес читателя.

6. Телефон читателя.

7. Дата выдачи читателю конкретной книги.

8. Срок, на который конкретная книга выдана читателю.

9. Дата возврата книги.

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

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

1. Авторы. Таблица предназначена для хранения сведений об авторах издания.

2. Книги. Таблица предназначена для хранения сведений о книгах.

3. Издательства .Таблица предназначена для хранения сведений об издательствах.

4. Хранилище. Таблица предназначена для описания места хранения книг.

5. Выдача .Таблица предназначена для хранения сведений о выданных книгах.

6. Читатели .Таблица предназначена для хранения сведений о читателях библиотеки.

Выбор необходимых полей таблиц

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

Исходя из вышесказанного, определяем поля в выбранных таблицах и тип хранимых данных.

· код автора – числовое поле, предназначено для однозначного определения каждого конкретного автора в базе данных;

· фамилия автора – символьное поле, не более 50 символов;

· имя автора – символьное поле, не более 25 символов;

· отчество автора – символьное поле, не более 25 символов.

· код книги – числовое поле, предназначено для однозначного определения каждой конкретной книги в базе данных;

· название книги – символьное поле, не более 256 символов;

· аннотация – текстовое поле;

· дата поступления в библиотеку ;

· место хранения .
Издательства:

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

· название издательства – символьное поле, не более 256 символов;

· город, где расположено издательство – символьное поле, не более 25 символов.

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

· номер комнаты – числовое поле;

· номер стеллажа – числовое поле;

· номер полки – числовое поле.

· код выдачи – числовое поле, предназначено для однозначного определения каждой конкретной выдачи в базе данных;

· номер выданной книги – числовое поле;

· код читателя – числовое поле;

· срок выдачи (количество дней);

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

· фамилия – символьное поле, не более 50 символов;

· имя – символьное поле, не более 50 символов;

· отчество – символьное поле, не более 50 символов;

· адрес – символьное поле, не более 256 символов;

· телефон – символьное поле, не более 20 символов.

Выбор уникальных полей

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

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

· Авторы – код автора .

· Книги – код книги .

· Издательства – код издательства .

· Хранилище – код места .

· Выдача – код выдачи .

· Читатели номер билета .

Назначение связей между таблицами

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

· один-к-одному – каждая запись таблицы А не может быть связана более чем с одной записью таблицы Б;

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

· многие-ко-многим – каждая запись в таблице А может быть связана со многими записями в таблице Б, а каждая запись в таблице Б – со многими записями в таблице А (например, у каждого учащегося может быть несколько преподавателей, а у каждого преподавателя может быть много учеников).

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

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

В нашей базе данных установим следующие типы связей между таблицами:

1. Авторы – Книги. Здесь связь многие-ко-многим. у любого автора может быть более одной книги, и любая книга может быть написана несколькими авторами. Поэтому вводим вспомогательную таблицу «Авторы–книги» со следующими полями:

2. Книги – Издательства. Здесь связь многие-ко-многим. любая книга может быть издана несколькими издательствами и любое издательство издает не одну книгу. Поэтому вводим еще одну вспомогательную таблицу «Книги–издательства» со следующими полями:

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

4. Книги – Выдача. Здесь связь один-ко-многим. т.е. одна и та же книга может быть выдана несколько раз в разные даты разным читателям. Поэтому поле «Номер выданной книги» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Книги» и «Выдача» первичным ключом «Код книги» и внешним ключом «Номер выданной книги».

5. Читатели – Выдача. Здесь связь один-ко-многим. т.е. одна и та же книга может быть выдана несколько раз разным читателям в разные сроки. Поэтому поле «Код читателя» в таблице «Выдача» определяем как внешний ключ, и связываем таблицы «Читатели» и «Выдача» первичным ключом «Номер читательского билета» и внешним ключом «Код читателя».

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

Правило 1: каждое поле таблицы должно представлять уникальный тип информации.

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

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

В спроектированной нами базе данных все таблицы (за исключением вспомогательных «Авторы – книги» и «Издательства – книги») содержат первичный ключ.

Правило 3: для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.

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

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

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

Наполнение базы данных, создание форм и отчетов

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

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

Полученная схема данных разработанной БД в MS Access представлена на рис. 4.1.

Рис. 4.1. Схема данных разработанной БД в Microsoft Access

1. Дайте определение информационной системы.

2. Поясните понятие базы данных.

3. Что такое предметная область?

4. Дайте определение СУБД.

5. Что такое модель данных?

6. Поясните основные принципы реляционной модели данных.

7. Поясните особенности СУБД Microsoft Access.

8. Каковы основные объекты базы данных Access?

9. Поясните структуру таблицы Access.

10. Поясните понятия: запрос, форма, отчет, страница доступа к данных, макрос, модуль.

11. Каковы основные этапы проектирования базы данных?

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

13. Поясните понятия: первичный ключ, внешний ключ.

14. Каково назначение связей между таблицами?

15. Поясните основные типы связей между таблицами.

16. В чем заключается нормализация отношений базы данных?

188.123.231.15 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам.

/ Базы данных

поле – это минимальный элемент базы данных, содержащий однотипную информацию;

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

Классификация баз данных

По содержанию хранимой информации:

фактографические БД — содержат данные, представляемые в краткой форме, в строго фиксированных форматах

(бумажные картотеки: библиотечный каталог, каталог видеотеки и др.)

документальные БД – содержат данные в виде документов, которые могут включать различную информацию: текстовую, графическую, мультимедийную, звуковую

(архивы документов: архив судебных дел, архив исторических документов и др.)

По способу хранения данных:

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

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

По структуре организации данных (модели данных)

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

Примеры базы данных

Примеры базы данных

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

каждый объект-потомок связан только с одним объектом-предком вышележащего уровня иерархии;

связи между объектами одного уровня не допускаются;

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

Иерархической базой данных является каталог папок Windows:

Примеры базы данных

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

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

Примеры базы данных Примеры базы данных

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

Реляционные базы данных — это БД, в которых все данные организованы в виде таблиц, между которыми установлены отношения(relation — отношение)

Примеры базы данных

Пример простой реляционной БД:





Внимание, только СЕГОДНЯ!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *